|
|
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
правильно заданный вопрос содержит в себе половину ответа, а то и больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2007, 16:32 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
maXmo OLEG_2005Проблема в том, что несколько потоков могут одновременно изменять данные и читать. Некоторые потоки периодически обходят контейнеры, выполняя расчёты, выдавая данные, другие получив данные из сети обновляют данные контейнеров.видишь ли, контейнер к этому уже отношения не имеет, т.к. он не будет твоему коду мешать работать, и если твой код требует какой-то синхронизации, тебе следует это требование сформулировать и реализовать и тип синхронизации будет полностью зависеть от этих требований. OLEG_2005Можно пояснить идею с двумя буферами?можно, если скажешь, что пояснять. Непонятно сама идея использования двух буферов - один для записи и для чтения. Есть несколько потоков, одни изменяют контейнер, другие читают из него. Ты предлагаешь записывать данные в два контейнера? Можно подробно описать идею с двумя буферами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 08:35 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
maXmoправильно заданный вопрос содержит в себе половину ответа, а то и больше. В процессе обсуждения мною задавалось несколько вопросов. Основонй вопрос заключался в том, каким образом лучше синхронизировать данные в stl-контейнере map при наличии нескольких потоков обновляющих данные и нескольких потоках читающих данные. Простейший вариант видимо заключается в доступе к контейнеру только одного потока. У меня есть несколько потоков, которые должны периодически обходить весь контейнер и в этом случае во время обхода другие потоки будут не смогут получить доступ к никаким данным контейнера и эффективность прогрммы может быть снижена. Втореая часть вопроса заключалась в том, нужно ли контейнер помещать в класс, в котором инкапсулирована синхронизация доступа или отдать её на откуп классам, которые должны обращать к данным (классы содердат укащатель на контйнер)? Прошу прощения за корявость изложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 10:35 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005В процессе обсуждения мною задавалось несколько вопросов. Основонй вопрос заключался в том, каким образом лучше синхронизировать данные в stl-контейнере map при наличии нескольких потоков обновляющих данные и нескольких потоках читающих данные. Простейший вариант видимо заключается в доступе к контейнеру только одного потока. У меня есть несколько потоков, которые должны периодически обходить весь контейнер и в этом случае во время обхода другие потоки будут не смогут получить доступ к никаким данным контейнера и эффективность прогрммы может быть снижена. Втореая часть вопроса заключалась в том, нужно ли контейнер помещать в класс, в котором инкапсулирована синхронизация доступа или отдать её на откуп классам, которые должны обращать к данным (классы содердат укащатель на контйнер)? Прошу прощения за корявость изложения. 1. Простейший способ блокировать все операции с контейнером. 2. Желательно, что бы класс занималься отдельной задачей. Поэтому можно создать объект владеющий контейнером (о1) с необходимыми методами доступа к нему, объект блокиратор (о2) и объект прокси (о3), который предоствляет доступ к о1, блокируя необходимые методы о1 нужными способами по средством блокираторов о2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 11:39 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
ну я же сказал, что если ты в начале заполняешь контейнер , а потом он не меняется или меняется очень редко, то контейнер после заполнения никак не нарушит логику твоего кода, то есть от кода stl результат твоего алгоритма не будет зависеть. Контейнер – просто контейнер, а в нём содержатся <объекты>, за работу которых контейнер никак не отвечает и не влияет. Для реализации синхронизации, если таковая требуется, тебе хватит только знания работы твоего кода . И если требуется, чтобы определённые операции в твоём коде выполнялись атомарно, так и делай, эти требования ты не озвучил. Конечно, ограничение доступа одним потоком будет работать в любом случае. Вспомним, чего ты боялся: OLEG_2005Честно говоря, не нашёл точных условия, которые делают итераторы контейнера недействительными?если ты не увеличиваешь число объектов в контейнере, а просто обновляешь поля объектов (буде таковые содержатся там), итератор останется действительным, синхронизировать потребуется только (крайне) редкие операции увеличения числа объектов в контейнере, а также всё , что требуется по техническому заданию. Если тебе нужно шарить контейнер между кучей пишущих и кучей читающих потоков, идея двойной буферизации, боюсь, уже не прокатит. Она катит в двухпоточном контексте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 11:50 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005 maXmoправильно заданный вопрос содержит в себе половину ответа, а то и больше. В процессе обсуждения мною задавалось несколько вопросов. Основонй вопрос заключался в том, каким образом лучше синхронизировать данные в stl-контейнере map при наличии нескольких потоков обновляющих данные и нескольких потоках читающих данные. Простейший вариант видимо заключается в доступе к контейнеру только одного потока. У меня есть несколько потоков, которые должны периодически обходить весь контейнер и в этом случае во время обхода другие потоки будут не смогут получить доступ к никаким данным контейнера и эффективность прогрммы может быть снижена. Втореая часть вопроса заключалась в том, нужно ли контейнер помещать в класс, в котором инкапсулирована синхронизация доступа или отдать её на откуп классам, которые должны обращать к данным (классы содердат укащатель на контйнер)? Прошу прощения за корявость изложения. Как уже было сказано, тут больше всего подходят блокировки на чтение и запись (Read Write Locks). Вообще на эту тему есть много теоретического материала. ищи в гугле: Задача "Читатели Пиcатели". Блокировка на чтение запись работет так: Поток можно заблокировать либо для чтения либо для записи. При блокировки для записи, никакие потоки не могут заблокировать ресурс ни для чтения ни для записи. При блокировки для чтения любой другой поток может так же заблокировать ресурс для чтения (читать могут много потков параллельно), но ни один поток не может заблокировать ресурс для записи. Потоки, которые обходят весь контейнер могут менять его размер (добавлять или удалять элементы)? Если контейнер сразу создается определенного размера, а потом меняются только его элементы, то достаточно блокировать только доступ к элементам. Иначе придется блокировать весь контейнер. Если некоторые потоки только изменяют элементы, некоторые изменяют размер контейнера, а некоторые только читают то для большей эффективности можно использовать 2 RW блокировки, одна блокирует весь контейнер (либо на чтение либо на запись), другая блокирует доступ к элементам. Однако тут надо быть осторожным, чтобы не получить deadlock. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 12:22 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Должно быть примерно так: Потоки которые только читают: блокируют контейнер для чтения, потом нужный элемент для чтения. Потоки, которые изменяют элементы (но не изменяют размер контейнера): блокируют контейнер для чтения, потом нужный элемент для записи. Потоки, которые добавляют и удаляют элементы (изменяют размер контейнера): блокируют контейнер для записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2007, 12:38 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Пока действительно при записи размер контейнера не изменяется, изменяется только значения полей элементов контейнера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2007, 08:40 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Sandro_KДолжно быть примерно так: Потоки которые только читают: блокируют контейнер для чтения, потом нужный элемент для чтения. Потоки, которые изменяют элементы (но не изменяют размер контейнера): блокируют контейнер для чтения, потом нужный элемент для записи. Потоки, которые добавляют и удаляют элементы (изменяют размер контейнера): блокируют контейнер для записи. Спасибо за интересную идею, надо будет её обдумать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2007, 08:43 |
|
||
|
|
start [/forum/topic.php?fid=57&msg=34593562&tid=2028679]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
162ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
2ms |
| others: | 248ms |
| total: | 523ms |
| 0 / 0 |
