freepascal.ru

Да ничем не отличаются. В винде InitCriticalSection вызывает windows.InitializeCriticalSection, в других системах, понятное дело, другая реализация.
Я в свое время предлагал команде просто сделать InitializeCriticalSection алиасом для InitCriticalSection, чтобы не приходилось дельфевый код допиливать. Мне ответили - погодь, у нас тут ветка выделенная есть, мы в ней ща ваще все связанное с потоками перепишем. Ну и благополучно забыли про это...

а критические секции плохое влияние в однопоточных приложениях имеют ?

как писал выше у меня есть обращение к БД и оно должно быть поочередно.
90% обращений через обертки подобные этой :

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

function ExecSQL(vtr: TJvUIBTransaction; const vSQL: string;
  vParams: array of variant; const DefaultValueIfNull : Variant = ''): Variant;


они вынесы в отдельный модуль и используются из разных проектов
если я тело процедуры обрамлю критической секцией это никак не скажется на других проектах ? на форуме пробегало про IsMultiThread но я так понял что это дело только в DLL и мне не грозит
или не морочить голову и добавить параметр UseMultiThread и по нему ориентироваться ?

Добавлено спустя 2 минуты 32 секунды:
да и надо ли при использовании BeginThread выставлять IsMultiThread ?

Добавлено спустя 33 минуты 56 секунд:
эксперемент показал что IsMultiThread выставляется сразу после BeginThread

тобишь весь код можно обрамить в if IsMultiThread then
главное не забыть инициализировать секции так как это должо произойти раньше BeginThread

а критические секции плохое влияние в однопоточных приложениях имеют ?

Нет неимеют.

ну вот отработал несколько дней все хорошо, поставил на другую машину все плохо.

по тому логу что существует сейчас видно следущее

1, отработал
2, отработал
3, отработал
1, вошел в секцию
2, подошел к секции стопарнулся
1, вышел из секции
3, вошел в секцию
3, вышел из секции
1, вошел в секцию
1, вышел из секции


второй так и висит =(
что можно добавить в лог чтобы было понятнее кто там о чем думает.
как это сворой управлять ?

Основное правило - блокировка не должна быть длительной. Что именно у тебя делается в рамках CS?

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

как другой вариант поток мог умереть, но секцию отпустил бы, я везде использую try finally да и отработало это под нагрузкой несколько дней, значит грубых ошибок точно нет.

Добавлено спустя 8 минут 8 секунд:
в МСДН пишут

После того, как поток получит в монопольное использование критическую секцию, он может делать дополнительные вызовы функций EnterCriticalSection или TryEnterCriticalSection, не блокируя исполнение своего кода. Это предохраняет поток от самоблокировки во время ожидания критической секции, которой он уже владеет.

а в лине у меня кажется получилась самоблокировка =/ или эт я чет не понял, надо будет перепроверить.

Ну, вообще говоря, простые критические секции работают практически случайно: если несколько потоков ожидают входа в CS, то какой войдет предсказать невозможно. Поэтому блокировка и должна быть по возможности короткой. Если важно соблюсти правило FIFO - нужно использовать более сложные объекты синхронизации: queue lock.

Вообще, обращение к базе данных - по определению очень длительная операция. Тут можно посоветовать завести отдельный поток, который пишет в базу, тогда в рамках CS надо будет просто ставить ему задания в очередь, что практически мгновенно.

нашел вроде. я же насовал этих try\finally как игрушек на новогоднюю елку, код стал не самым читабельным, и вот в самом дальнем углу, который работает только с созвездии близнеца написал try\except

так что это была грубая ошибка по невнимательности =(

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

Max Rusov писал(а):Вообще, обращение к базе данных - по определению очень длительная операция. Тут можно посоветовать завести отдельный поток, который пишет в базу, тогда в рамках CS надо будет просто ставить ему задания в очередь, что практически мгновенно.

к сожалению мне не пойдет, так как я читаю из БД и пока мне не ответят надо ждать.

но все равно спасибо за внимание =)