Здравствуйте,
есть два потока и объект "список"
как правильнее организовать критические секции для монопольного доступа к объекту?
делают ли так:
вход в критическую секцию выполняется в методах объекта список
т.е. при любом обращению к методам объекта в его методах выполняется вход в критическую секцию а при завершении метода — выход. При этом как я считаю из другой нити нельзя будет обратится к методам этого объекта (так ли это?)

или же нужно делать обрамление

EnterCriticalSection(..);
 Object->SomeMethod();
LeaveCriticalSection(..);

а не внутри SomeMethod()

Здравствуйте, butcher, Вы писали:

B>вход в критическую секцию выполняется в методах объекта список
B>т.е. при любом обращению к методам объекта в его методах выполняется вход в критическую секцию а при завершении метода — выход.

Совершенно верно

B>При этом как я считаю из другой нити нельзя будет обратится к методам этого объекта (так ли это?)

Нельзя это слишком сильно сказано. Просто пока один поток работает находится внутри метода работы со списком, другой будет висеть на вызове метода, пока первый не вызовет LeaveCriticalSection.

Здравствуйте, butcher, Вы писали:

B>или же нужно делать обрамление
B>

B>EnterCriticalSection(..);
B> Object->SomeMethod();
B>LeaveCriticalSection(..);
B>

B>а не внутри SomeMethod()

Да и так и так можно. Смотря кто обеспечивает потокобезопасность. Если объект "список" то вставлять такие вызовы в каждом методе. Во втором случае ты ограничиваешь доступ к объекту в целом и такие вызовы должен будешь ставить для каждого обращения к нему. Вопросы дизайна. В первом случае — потокобезопасный класс, во втором — соответсвенно нет.

B>т.е. при любом обращению к методам объекта в его методах выполняется вход в критическую секцию а при завершении метода — выход. При этом как я считаю из другой нити нельзя будет обратится к методам этого объекта (так ли это?)
Как раз так и надо. У тебя получится потокобезопасный объект, который сможет использовать любое приложение.

На самом деле тут есть "подводные камни". Если у тебя есть ф-я для доступа к элементу списка типа Get, и она возвращает ссыку, или указатель на данные хранящиеся в списке, то своей критической сецией внутри ф-ии Get ты не обезопасешь себя, так как после выхода из этой ф-ии доступ до списка получит другой поток и сможет удалить элемент содержащий данные на которые ты ранее получил ссылку, и данные могут быть разрушены. Поэтому в таких случаях для списка делается методы Lock и Unlock и пишется:

list.Lock();

Object &obj=list.Get();
// чего-то делаем с obj

list.Unlock();

Здравствуйте, butcher, Вы писали:

[]

Думаю, что надо разделить защищаемые ресурсы по времени жизни.

Для ресурсов с короткой жизнью использовать синхронизацию
внутри методов класса

Для ресурсов с длинной жизнью реализовать методы
Lock() — вход в критическую секцию
Unlock() — выход из критической секции