всем доброго дня.

диалог с самим собой:
- класс содержит вектор доступ к которому производится из нескольких потоков.
- значит пишем обертку на вектором дабы не разбрасывать блокировки по коду.
- написал.
- о! эту переменную-член тоже нужно защитить!
- защитил.
- гм.. так для всего этого достаточно одного мьютекса. выкидываем обертку %)
- епс! блокировки разбросаны по всему коду! завтра уже не вспомню эту мозговыворачивающую логику/порядок блокировок! - убить весь код и начинать заново! %)
- ага! тут же еще и map нужно блокировать с частичной зависимостью от логики блокировки вектора и этой переменной! %)
- так по какому же принципу, и на основании чего, все это дело проектируется?! наверное, нужно обобщать фрагменты кода имеющие общие правила/логику/порядок блокировки...
- епс, один класс состоит из трех! два из которых ссылаются на один мьютекс! всего мьютексов два. - еще более мозговыворачивающая логика получилась!!!

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


Это сообщение отредактировал(а) boostcoder - 7.6.2011, 12:11

boostcoder


Многопоточный код простым бывает редко, не забывай подробно комментировать код.

А порядок блокировки всегда должен быть один и тот же. Если не уверен или не можешь это обеспечить - используй boost/std::lock().

Добавлено через 4 минуты и 4 секунды

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

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

Добавлено через 5 минут и 20 секунд

имел ввиду, логику взаимодействия блокировок, с блокировками других членов класса. и тут начинается самое интересное, т.е. расползание спаггети %)

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

не-не-не! такого делать нельзя. есть взаимные блокировки, а есть взаимоисключающие.

Добавлено @ 16:08
к тому же, если сделать так как Вы предложили, то некоторая часть методов класса(хотя, по идее все), при вызове, будет доступна только одному потоку. а ситуация которую описал я выше, требует чтоб часть методов могла работать с одним потоком, другая же часть - с другим потоком. одновременно! иначе бы мне потребовался только один мьютекс, и вопроса подобного бы не возникло...

Это сообщение отредактировал(а) boostcoder - 6.6.2011, 16:09

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

xvr, я почти так и делаю..

что-то вроде прокси и получилось... но как-то через попу...

Добавлено через 1 минуту и 28 секунд
вопрос-то был о внятных книжках/статьях по проектированию многопоточного кода.

http://www.amazon.com/Patterns-Parallel-Pr.../ref=pd_sim_b_5
http://www.amazon.com/Patterns-Parallel-So...mp;sr=8-2-spell

вот за это спасибо!
думаю вторая пока подождет.