Многопоточность в Linux

[qivi]

Почему при компиляции приложения с дополнительным потоком в Linux я получаю:

Note: DWARF debug information cannot be used with smart linking on this target, switching to static linking

То есть отключается умная компоновка (Проект=>Параметры проекта...=>Параметры компилятора=>Компоновка=>Умная компоновка). Это не допил? Баг? Можно ли рассчитывать что это будет исправлено?

Почему в Linux запуск дополнительного потока приводит к тому что один из процессоров грузиться на 100%!!! а второй идёт на холостом режиме? Это можно как то уравновесить?

[Kitayets]

какая версия fpc ?

Добавлено спустя 14 минут 7 секунд:
во всяком случае загрузку цпу на 100% не подтверждаю.

fpc - Free Pascal Compiler version 2.4.2 [2011/02/09] for x86_64

система fedora 15 x86_64

вот пара скриншотов с моим тестовым приложением (отрисовка конечно в главном потоке, который в заголовке не учитывается).

Добавлено спустя 6 минут 53 секунды:
на счёт сообщения:

Note: DWARF debug information cannot be used with smart linking on this target, switching to static linking

оно говорит, что при умной компоновке не будет доступна отладка в gdb. Т.е. либо возможность отладки либо смарт линкинг. Таким образом дебажешь программу в статической компоновке а релиз можно сделать и с умной.

Добавлено спустя 3 минуты 6 секунд:
кстати в винде моё приложение, если запустить под 100 потоков, грузит оба ядра core2duo на 100%, а под линуксом пофиг, хоть 2 хоть 200.

[qivi]

оно говорит, что при умной компоновке не будет доступна отладка в gdb. Т.е. либо возможность отладки либо смарт линкинг. Таким образом дебажешь программу в статической компоновке а релиз можно сделать и с умной.

Спасибо за подсказку

На счёт загрузки процессоров, пронаблюдал подольше, они периодически меняются, видимо это всё таки что то системное (может даже аппаратное):


Хотя скрен не очень удачный, перед тем как его сделал тестил, дак процессоры на продолжительных интервалах поочерёдно грузились под 100.

[stikriz]

кстати в винде моё приложение, если запустить под 100 потоков, грузит оба ядра core2duo на 100%, а под линуксом пофиг, хоть 2 хоть 200.

У тебя там слипы? Иди диск юзает? Или в порты пишет напрямую? С какого перепуту многопоточное приложение не должно грузить все ядра на 100% пока не выполнить задачу? Должно грузить...

[qivi]

Не совсем по теме, но думаю новой темы вопрос не заслуживает.

Обновил под WIN32 Лазарус, главное обновился ФПЦ, и теперь он мне ругается следующим образом:

Код: Выделить всё

gm.pas(1448,12) Warning: Symbol "Resume" is deprecated

То есть "Resume", устарело, а что в замен его?

[Sergei I. Gorelkin]

В том случае, когда поток создется в остановленном виде, для запуска вместо Resume используется метод Start. В остальных случаях не используется ничего.

[qivi]

Спасибо.

[qivi]

А можно ли передать параметр в синхронизируемый метод?
Конструкцию:

Код: Выделить всё

Synchronize(@VIG_MO(n));

паскаль бракует, говорит что вместо второй открывающейся скобки ожидается закрывающая.

[Sergei I. Gorelkin]

Нельзя туда параметры передавать.

[qivi]

Ещё один вопросик мучает, может дурацкий, но всё же...
Один дополнительный поток создаёт другой доп поток, синхрометоды последнего будут синхронизироваться с потоком который его создал или с основным потоком приложения?

[VirtUX]

А можно ли передать параметр в синхронизируемый метод?

Определите нужную переменную в том модуле, - из которого вызываете синхронизируемый метод. В методе обрабатывайте эту переменную. Перед вызовом методу в потоке инициалицируйте эту переменную. Главное, чтоб эту переменную не использовали другие потоки, иначе нужно использовать критические секции.

синхрометоды последнего будут синхронизироваться с потоком который его создал или с основным потоком приложения?

все методы принадлежат основному потоку, кроме объявленных в классе потока.

Добавлено спустя 1 минуту 46 секунд:
И вообще: синхронизируемые методы должны быть вне каких-либо потоков. Хотя это и не принципиально, но, ИМХО, безопасней.

[qivi]

Определите нужную переменную в том модуле, - из которого вызываете синхронизируемый метод. В методе обрабатывайте эту переменную. Перед вызовом методу в потоке инициалицируйте эту переменную. Главное, чтоб эту переменную не использовали другие потоки, иначе нужно использовать критические секции.

Спасибо, но там я костыль давно уже подставил. Я только не в модуле объявил переменную, а в классе потока, следовательно к ней получили доступ все методы класса потока включая те что я вызываю на синхронизацию.

все методы принадлежат основному потоку, кроме объявленных в классе потока.

Пардон не понял, если обявление классов обоих доп потоков находится просто в модуле (в разделе имплементатион), а переменную типа второго доп потока я объявляю и вызываю в первом доп потоке, с кем будет синхронизироваться второй доп поток?

[Sergei I. Gorelkin]

Синхронизация всегда происходит с основным потоком (тем, котовый неявно создается при старте приложения).
Принадлежность методов или свойств не играет никакой роли, любой метод любого класса может быть выполнен в любом потоке.