Подскажите, пожалуйста, правильно ли я делаю:

1) я вставляю EnterCryticalSection первым оператором критической процедуры, к которой обращаюсь из нескольких потоков. Может быть, EnterCryticalSection нужно ставить перед командой потока, вызывающей эту процедуру?

2) я вставляю EnterCryticalSection первым оператором критической процедуры, к которой обращаюсь из нескольких потоков. При этом в процедуру передается параметр. При одновременном обращении к процедуре нескольких потоков параметры будут конфликтовать (затирать друг друга)?

3) я вставляю EnterCryticalSection первым оператором критической процедуры, к которой обращаюсь из нескольких потоков.  Чтобы избежать зависания использую TryEnterCriticalSection:


Переменная Cnt будет общая для всех потоков или каждый поток работет со своей копией Cnt?

Спасибо.

она лежит в стеке, а у каждого потока свой стек, поэтому тут все нормльно


для типов не являющихся скрытыми указателями - все нормально, для являющихся - нормально при условии, что IsMultiThread=true

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

Если это у тебя VCL поток, и ты пытаешься избежать зависания пользовательского интерфейса, то в цикле надо сделать Application.ProcessMessage.


Со своей копией. Она тоже в стеке потока.

ЗЫЖ Вообще для входы/выходы из критических секций лучше всего в Try-Finally брать. ТАк... на всякий  случай.

Нет.
Эта переменная для менеджера памяти Delphi. К синхронизации она не имеет отношения.

как это не имеет? по твоему увеличить счетчик ссылок на строку (например при передаче ее в процедуру) можно одинаково в многопоточном и однопоточном приложениях?

Прошу прощения, как оказалось счетчик ссылок строки всегда обрабатывается атомарно, даже если есть всего один поток.
Но при передаче интерфейса в процедуру (а точнее при выходе из нее) все равно нужен IsMultiThread

Ну, во-первых, ниче не понял. По подробнее можно?

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

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

Топикстартер спрашивал нормально ли будет сделать так:

В этом коде действия, подставляемые компилятором после начала процедуры но до первой строки пользовательского кода (и после последней строки но до возврата из процедуры) выполняются вне критической секции пользователя. Значит нужно включить использование критической секции менеджера памяти с помощью IsMultiThread

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

задай вопрос конкретнее

Ну и я о том же 


Полностью согласен.


Не понял, как звучит обратное утверждение?

Мне кажется, что мы об одном и том же... Я лично не сталкивался с флагом IsMultiThread, только читал про него. Многопоточные приложения писал и пишу, но пользую TThread, поэтому не думаю об этом флаге.

На вопрос топикастера ты ответил:


Я утверждаю, что установки этого флага не достаточно. Т.к. этот флаг будет отвечать за выделение памяти под данные из разных потоков, но не за доступ к ним. Доступ к ним надо синхронизировать отдельно.
А в случае топикастера вообще все параллельно. У него данные только в стеке, так что для каждого потока свои будут  Вот если у него вместо "..." есть код, который работает с "общими" для потоков ресурсами, то тогда в любом случае ему надо делать синхронизацию в ручную.