|
|
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Обычно при синхронизации я использую критические секции для защиты переменных класса. Скажите, пожалуйста, для работы с контейнерами STL (map, vector) достаточно ли использования критической секции? Или использовать мьютексы? Один из поток обновляет данные в контейнеры map (добавляет или изменяет значения для данного ключа), другие потоки могут читать данные из контейнера? Честно говоря, не нашёл точных условия, которые делают итераторы контейнера недействительными? Может кто подскажет, какие проблемы могут быть при использовании контейнеров в многопоточных программах и в как избегать недействительности итераторов контейнера или подскажет ссылку на информацию по данному вопросу? Заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 16:31 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
давай почитаем ман Vector reallocation occurs when a member function must increase the sequence contained in the vector object beyond its current storage capacity. Other insertions and erasures may alter various storage addresses within the sequence. In all such cases, iterators or references that point at altered portions of the sequence become invalid. If no reallocation happens, only iterators and references before the insertion/deletion point remain valid. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 17:11 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
так что синхронизируй доступ и будет тебе счастье ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 17:12 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Так я и спрашиваю, каким образом в данном случае надо синхронизировать доступ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 17:15 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Не будет счатья. Инвалидация итераторов совершенно не связана с многопоточностья (чти цитату) Инвалидироваться может любой итератор вектора или деки после опреации вставки или удаления, независимо от того много у тебя потов ил один. Просто итераторы не следует запоминать. И уже как следствие - не след итерироваться по контейнеру, в то время когда в него пытаются вставлять, удалять. Естественно не следует из двуж потоков модифицировать вектор. Можно и мьютексом защитить, но лучше блокировка чтение.запись ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 17:19 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
blindedНе будет счатья. Инвалидация итераторов совершенно не связана с многопоточностья (чти цитату) Инвалидироваться может любой итератор вектора или деки после опреации вставки или удаления, независимо от того много у тебя потов ил один. Просто итераторы не следует запоминать. И уже как следствие - не след итерироваться по контейнеру, в то время когда в него пытаются вставлять, удалять. Естественно не следует из двуж потоков модифицировать вектор. Можно и мьютексом защитить, но лучше блокировка чтение.запись но лучше блокировка чтение.запись - что вы здесь имеете в виду? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 17:24 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005Так я и спрашиваю, каким образом в данном случае надо синхронизировать доступ? полностью синхронизировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 17:26 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
пока итератор не изъюзаешь, критическую секцию не покидать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 17:28 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Т.е. чтобы гаранитровать корректную работу нужно во время выполнения цикла запретить доступ дргугих потоков к контейнеру. Я использую контейнер map. CALCULATED_TI_DATA::iterator calculatedDataIterator; for (calculatedDataIterator = calculatedTiBuffer.begin(); calculatedDataIterator != calculatedTiBuffer.end(); calculatedDataIterator++) { Что-нибудь делаем с элементами контейнера } ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 17:28 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005 blindedНе будет счатья. Инвалидация итераторов совершенно не связана с многопоточностья (чти цитату) Инвалидироваться может любой итератор вектора или деки после опреации вставки или удаления, независимо от того много у тебя потов ил один. Просто итераторы не следует запоминать. И уже как следствие - не след итерироваться по контейнеру, в то время когда в него пытаются вставлять, удалять. Естественно не следует из двуж потоков модифицировать вектор. Можно и мьютексом защитить, но лучше блокировка чтение.запись но лучше блокировка чтение.запись - что вы здесь имеете в виду? Посмотри например здесь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 18:12 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005 пишет: > Скажите, пожалуйста, для работы с контейнерами STL (map, vector) > достаточно ли использования критической секции? Да, достаточно. Или использовать > мьютексы? Или секции, или мьютексы. Мьютексы нужны только при межпроцессном взаимодействии, поэтому лучше секции. Один из поток обновляет данные в контейнеры map (добавляет или > изменяет значения для данного ключа), другие потоки могут читать данные > из контейнера? Нет. Весь доступ, как по чтению, так и по записи, должен быть защищен. Честно говоря, не нашёл точных условия, которые делают > итераторы контейнера недействительными? Прописаны и в стандарте, и в документации. Явно для каждой операции. Ищи лучше. Может кто подскажет, какие > проблемы могут быть при использовании контейнеров в многопоточных > программах Никаких не должно быть, только надо доступ к ним защищать. и в как избегать недействительности итераторов контейнера или > подскажет ссылку на информацию по данному вопросу? Заранее спасибо. При выполнении методов, инвалидирующих итераторы, надо заново инициализировать итераторы, и все. Это кстати написано хорошо у Меерса в Effective STL. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2007, 19:11 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
MasterZiv OLEG_2005 пишет: > Скажите, пожалуйста, для работы с контейнерами STL (map, vector) > достаточно ли использования критической секции? Да, достаточно. Или использовать > мьютексы? Или секции, или мьютексы. Мьютексы нужны только при межпроцессном взаимодействии, поэтому лучше секции. Один из поток обновляет данные в контейнеры map (добавляет или > изменяет значения для данного ключа), другие потоки могут читать данные > из контейнера? Нет. Весь доступ, как по чтению, так и по записи, должен быть защищен. Честно говоря, не нашёл точных условия, которые делают > итераторы контейнера недействительными? Прописаны и в стандарте, и в документации. Явно для каждой операции. Ищи лучше. Может кто подскажет, какие > проблемы могут быть при использовании контейнеров в многопоточных > программах Никаких не должно быть, только надо доступ к ним защищать. и в как избегать недействительности итераторов контейнера или > подскажет ссылку на информацию по данному вопросу? Заранее спасибо. При выполнении методов, инвалидирующих итераторы, надо заново инициализировать итераторы, и все. Это кстати написано хорошо у Меерса в Effective STL. Posted via ActualForum NNTP Server 1.4 Большое спасибо за такой развёрнутый ответ. Но, всё равно остаётся вопрос. Если я ставлю критическую секцию в коде изменения контейнера и в коде обхода контейнера (а контейнер может сожержать достаточно много элементов и цикл быть длительным), то на врёмя обхода всего контейнера у меня блокируется доступ к элементам контейнера. Не приведёт ли это к снижению быстродействия? Хотя другого вариант, гарантируюшего коректную работу я не могу придумать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 09:24 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
> вопрос. Если я ставлю критическую секцию в коде изменения контейнера и в > коде обхода контейнера (а контейнер может сожержать достаточно много > элементов и цикл быть длительным), то на врёмя обхода всего контейнера у > меня блокируется доступ к элементам контейнера. Да, имено так. Не приведёт ли это к > снижению быстродействия? Может. Но делать нечего. Хотя другого вариант, гарантируюшего коректную > работу я не могу придумать. Его просто нет. Хотя можно цикл обработки написать так, чтобы он брал N-йый элемент из контейнера под мьютексом или секцией и затем освобождал контейнер. Это нужно наверное только если операции с элементами длинные. При этом сам элемент нужно скопировать из контейнера, поскольку после освобождения нет будет гарантии, что адрес этого объекта не поменяется всвязи с переаллокацией памяти или удалением элемента. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 10:53 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
MasterZiv Хотя можно цикл обработки написать так, чтобы он брал N-йый элемент из контейнера под мьютексом или секцией и затем освобождал контейнер. Это нужно наверное только если операции с элементами длинные. При этом сам элемент нужно скопировать из контейнера, поскольку после освобождения нет будет гарантии, что адрес этого объекта не поменяется всвязи с переаллокацией памяти или удалением элемента. Posted via ActualForum NNTP Server 1.4 Если я при переборе контейнера буду брать очередной элемент под мьютексом, то при переходе к следующему элементу нет гарантии правильности итератора (после особождения от мьютекса итератор может стать недействительным). Или я неправ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 11:26 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005 Большое спасибо за такой развёрнутый ответ. Но, всё равно остаётся вопрос. Если я ставлю критическую секцию в коде изменения контейнера и в коде обхода контейнера (а контейнер может сожержать достаточно много элементов и цикл быть длительным), то на врёмя обхода всего контейнера у меня блокируется доступ к элементам контейнера. Не приведёт ли это к снижению быстродействия? Хотя другого вариант, гарантируюшего коректную работу я не могу придумать. Приведет, если контейнер нужно обрабатывать паралельно несколькими нитями. Как вариант решения: Нужно завести 2 мютекса. 1. На изменение. 2. На чтение. Если флаг(мютекс) на чтение установлен, никакая нить ничего изменять не может. Зато все нити могут читать паралельно. Если установлен флаг(мютекс) на изменение то никто кроме единственной изменяющей нити не может производить никаких действий с обьектом. Не забудьте хранить и актуализировать количество паралельно читающих нитей. Вероятнее всего нужно будет создавать систему приоритетов, потому как пишущей нити будет очень тяжело забрать ресурс у нескольких перманетно читающих нитей. Также нужно контролировать атомарность измениния всей группы флагов(мютексов) защитив ее всю еще одним. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 11:41 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
onstat- пишет: > Как вариант решения: > Нужно завести 2 мютекса. > 1. На изменение. > 2. На чтение. .... > будет очень тяжело забрать ресурс у нескольких перманетно читающих нитей. > Также нужно контролировать атомарность измениния всей группы > флагов(мютексов) > защитив ее всю еще одним. Что-то сложновато как-то, да и не будет работать эта логика. Мьютексов надо иметь только один, а вот вид блокировки контейнера - трех видов. Чтение, требование записи и запись. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 13:49 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005 пишет: > Если я при переборе контейнера буду брать очередной элемент под > мьютексом, то при переходе к следующему элементу нет гарантии Еще раз что я предлагал. В цикле переменной цикла является i - номер элемента. В векторе или в последовательном контейнере. внутри тела цикла сначала захватывается мьютекс контейнера находится i-ый элемент. если не находится, мьютекс освобождается и цикл заканчивается. Он копируется куда-то, где потом будет использоваться. итераторы, если они использовались для поиска, уничтожаются (т.е. более не используются). освобождается мьютекс выполняется обработка скопированного элемента. цикл продолжается, увеличивается i. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 13:55 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
MasterZiv onstat- пишет: > Как вариант решения: > Нужно завести 2 мютекса. > 1. На изменение. > 2. На чтение. .... > будет очень тяжело забрать ресурс у нескольких перманетно читающих нитей. > Также нужно контролировать атомарность измениния всей группы > флагов(мютексов) > защитив ее всю еще одним. Что-то сложновато как-то, да и не будет работать эта логика. Мьютексов надо иметь только один, а вот вид блокировки контейнера - трех видов. Чтение, требование записи и запись. Posted via ActualForum NNTP Server 1.4 Почему только один? Я не силен в тредах. В Unix на семафорах у меня такое работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 14:05 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
onstat- пишет: > Почему только один? Я не силен в тредах. Я не буду отвечать. Ты лучше вместо этого опиши полностью подробно как предлагаешь это сделать. Но только IMHO не будет это полезно вопрошающему. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 14:19 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
MasterZiv Что-то сложновато как-то, да и не будет работать эта логика. почему не будет? 1. Проверяем мютексы на чтение ( с учетом приоритетности записи) и на запись, если кто то пишет ( или прриоритет записи высокий), спим пока не освободится. 2. Взводим мютекс защищающий группу(либо спим пока его не освободит другая нить). 3. Пытаемся установить флаг чтения либо записи. Если запись уже идет, либо кто то читает если нужно писать, не спим, повышаем приоритет записи, освобождаем мютекс защищающий группу, и переходим на п 1. Если чтение возможно увеличиваем счетчик читающих на единицу. Если приоритет записи выше нужного освобождаем мютекс группы и переходим на п 1. 4. освобождаем мютекс защищающий группу. 5.Делаем необходимые действия. 6. Взводим мютекс защиты группы, 7.Освобождаем мютексы записи/чтения но стачала уменьшаем счетчик читающих( если читали) или приоритет записи( если писали). 8. Освобождаем мютекс защиты группы. Подскажите где я не прав. На POSIX семафорах это реализовать проще, операция semop гарантирует атомарность (чтения) изменения всего набора(группы) семафоров . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 14:33 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
blindedНу вообще-то нужен 1 mutex и 2 счетчика Если будет один мютекс , нужно будет принудительно усыплять и будить нити. Если их будет несколько процесс сна можно будет автоматизировать( спать на мютексах) и просыпаться автоматом когда мютексы будут сброшены. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 14:47 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
onstat- пишет: > Если будет один мютекс , нужно будет принудительно усыплять и будить нити. > Если их будет несколько процесс сна можно будет автоматизировать( спать > на мютексах) и просыпаться автоматом когда мютексы будут сброшены. Да, это правильное замечание. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 17:23 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005 Если я при переборе контейнера буду брать очередной элемент под мьютексом, то при переходе к следующему элементу нет гарантии правильности итератора (после особождения от мьютекса итератор может стать недействительным). Или я неправ? Я могу заблуждаться . Для безопасного доступа к вектору нужно пользоваться не итератором, а оператором []. Это вносит неудобства, но целостность должно гарантировать. По поводу защиты. Изменение может быть двух видов 1. Изменение размера контейнера, для этого можно воспользоваться предложенным мною выше. 2. Изменение элемента контейнера, В этом случае для всех нитей можно завести общий список изменяемых обьектов в данный момент, и изменять разные элементы паралельно. При этом на весь контейнер нужно ставить мутекс на чтение, а непосредственно изменяемый элемент защищать мутексом на запись. ИЛИ Что бы не держать мутексы по количеству элементов можно создать пул мутексов и привязывать из него мутекс к конкретному изменяемому в данный момент элементу, количество мутексов в пуле должно быть приблизительно равно количеству одновреммено изменяемых элементов за одну транзакцию умноженное на количество нитей. Если в пуле свободных мутексов нет, то спать пока они не появятся в нужном количестве. Как идея? Продумать нужно, иначе борьба с дедлоками в конечном итоге может все похоронить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 20:36 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
onstat- пишет: > почему не будет? .... > Подскажите где я не прав. Вот что б я чего-то там понял. Разве этого не достаточно ? > 1. Проверяем мютексы на чтение и на запись, > если кто то пишет, спим пока не освободится. делаем дело, освобождаем мьютексы. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 20:44 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
onstat- пишет: > Для безопасного доступа к вектору нужно пользоваться не итератором, а > оператором []. Для безопасного ОТ ЧЕГО ? Впрочем, пофигу, это одно и то же. > По поводу защиты. > Изменение может быть двух видов > 1. Изменение размера контейнера, для этого можно воспользоваться > предложенным мною выше. Изменение может быть одного вида : "изменение". > 2. Изменение элемента контейнера, В этом случае для всех нитей можно > завести общий список изменяемых обьектов в данный момент, и изменять > разные элементы паралельно. Это - изменение не контейнера, а хранимого объекта. Это уже - проблема самого объекта. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 20:47 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
MasterZiv onstat- пишет: > почему не будет? .... > Подскажите где я не прав. Вот что б я чего-то там понял. Разве этого не достаточно ? > 1. Проверяем мютексы на чтение и на запись, > если кто то пишет, спим пока не освободится. делаем дело, освобождаем мьютексы. Posted via ActualForum NNTP Server 1.4 Проблема мютексов в отличие от POSIX семафоров в том что нельзя атомарно (( косистентно), (за один системный вызов)) проверить и изменить несколько штук( группу). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 20:53 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
MasterZiv Это - изменение не контейнера, а хранимого объекта. Это уже - проблема самого объекта. Posted via ActualForum NNTP Server 1.4 Изза одного изменяемого обьекта из 1000 вы предлагаете спать всем, кто даже не планирует иметь к нему доступ, Хотя это дело личное. Мое дело предложить, а автору топика решать как быть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.05.2007, 21:05 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Синхронизировать доступ нужно к контейнеру map. Хотелось бы решение максимально простое. А насчёт идеи отельно синхронизировать запись и чтение надо подумать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2007, 09:18 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
onstat- пишет: > Проблема мютексов в отличие от POSIX семафоров в том что нельзя > атомарно (( косистентно), (за один системный вызов)) проверить и > изменить несколько штук( группу). Я не говорил, что их надо одновременно лочить. Сначала один, на чтение, потом другой, на запись. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2007, 12:24 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
MasterZiv Разве этого не достаточно ? onstat- пишет: > 1. Проверяем мютексы на чтение и на запись, > если кто то пишет, спим пока не освободится. делаем дело, освобождаем мьютексы. MasterZiv Я не говорил, что их надо одновременно лочить. Сначала один, на чтение, потом другой, на запись. Posted via ActualForum NNTP Server 1.4 При установке мютекса на чтение никакая другая сессия через него пройти не сможет. А как же паралельное чтение? Когда всетаки освобождаем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2007, 13:22 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Здесь упоминали семафоры для решения данной задачи, инересно, а каким образом для решения задачи можно применить световоры? И всё же вопрос четкого ответа не прозвучало. Не понял идею с отдельной синхронизации для операций чтения и записи. Один из потоков периодически обходит контейнер map с помощью итератора и выполняет расчёты. В то же время другие потоки могут обновлять контейнер. Самый дубовый случай запретить доступ к контейнеру на время обхода его обхода и при обновлению. В простейшем случаем можно использовать один мьютекс (или критическую секцию). Может в моём случае это и прокатит, но, если размер контейнера довольно большой эффективность видимо значительно снизится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 15:19 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
2 OLEG_2005 Я в начале давал ссылочку на библиотеку. Там есть набор набор синхронизующих объектов, в том числе и RW блокировка. Код там не сложный. Почитай, там и доки к ней лежат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 15:31 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Там много документов. А в двух коротко идею можно объясниться. Просто есть идея написать класс, которые будет хранить данные в контейнеры map и о был потокобезопасным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 15:42 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Кстати забыл уточнить платформа Windows. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 15:48 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005Там много документов. А в двух коротко идею можно объясниться. Просто есть идея написать класс, которые будет хранить данные в контейнеры map и о был потокобезопасным. Не силен я виндовс, но там и для него реализания есть. Вопрос а надо-ли делать потоко-безопасный map или лучше сделать потоко-безопасный прикладной контейнер. Кстати а что будешь делать с итераторами по контейнеру? Их тоже переписывать? Тем не менне за выходные расковыряю или сам? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 17:07 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Попробую кратко описать задачу. Моя программа обменивается с подсистемой сбора данных (с датчиков снимаются аналоговые и дискретные сигналы и по опросу выдаюётся моей программе). В программе есть несколько контейнеров: текущие аналоговые сигналы, текущие дискретные сигналы и очередь событий. При получении данных от подсистемы сбора данные данные текущих состояний они помещаются в соответствующий контейнер. Этот же контейнер используется потоком котороый заниманется аръивирование текущих состояний (периодиский обходит контейнер, выполняет расчёты и пишет в БД). Использую контейнер map, в котором ключом является идентификатор аналогового или дискретного сигнала. Программа должна иметь возможность опрашивать несколько подсистем сбора данных. Пока я понимаю только вариант с запретом нескольких потоков одновременно обращаться к контейнеру с помощью мьютекса или критических секций. Но тогда при обходе контейнера не будет возможности обращаться к нему другим потоком. Хотя может быть по другому не сделаешь. В этом случае в контейнер могут писать несколько потоков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 17:23 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Пока копаю. Но других работоспособных и одновременно простых решений пока не вижу. Не хотелось бы усложнять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 17:29 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005Здесь упоминали семафоры для решения данной задачи, инересно, а каким образом для решения задачи можно применить световоры? Вот упрощенная версия, работает только в Unix. [SRC locks.h] /**************************=-OpenDSA-=****************************** This file is a part of OpenDSA project(http://sourceforge.net/projects/opendsa) It can be destributed independently of OpenDSA with safe license of OpenDSA. OpenDSA is destributed by GPL license. (04.06.2006). All rights reserved by (C) Konstantin Kaduk 2006. *******************************************************************/ #include <stdio.h> // standard I/O routines. #include <sys/types.h> // various type definitions. #include <sys/ipc.h> // general SysV IPC structures #include <sys/sem.h> // shared memory functions and structs. #include <errno.h> #include <string.h> /******************************************************************* *******************************************************************/ #ifndef SEM_LOCK_H #define SEM_LOCK_H extern int rc; // any results #define MAXSETSIZE 3 /******************************************************************* *******************************************************************/ union semun { int val; /* value for SETVAL */ struct semid_ds *buf; /* buffer for IPC_STAT, IPC_SET */ unsigned short *array; /* array for GETALL, SETALL */ /* Linux specific part: */ struct seminfo *__buf; /* buffer for IPC_INFO */ }; /******************************************************************* *******************************************************************/ #define LOC_SEM_CNT 3 class c_lock /******************************************************************* Class c_lock provide objects locking for reading and writing 1. READ locking Any concurent processes can read data which locked by another. Each process incerase semaphore(0) counter for place reading lock. When write lock was placed(semaphore(1)) by another process reading process will sleep while writing lock will be dropped. Counter is decreased when reding lock is dropped by current process. 2. Write locking Writing process sleeps while any another process is reading or writing data now.It wake ups when counter(semaphotre 1) of reading process is equal to zero. It places writing lock by two semaphores(1,2): Semaphore 1 is used for place writing lock (using for check by reading processes). Semaphore 2 is used for exclusive lock(only one process can use data at the same time). ////////End of original coment form Konstantin Kaduk //////////////////////// Remark1: /////// *******************************************************************/ { int s_set_id; struct sembuf s_sem_op[LOC_SEM_CNT]; union semun s_semun; unsigned short s_semarray[LOC_SEM_CNT]; //array for semop public: c_lock(int sem_id=0); ~c_lock(); int lock_init(int sem_id); void stat(const char* f_comment=NULL ); // print current values of semaphore void r_lock(); // place reading lock void r_unlock(); // decrease reading counter void w_lock(); // place writing lock void w_unlock(); // drop writing lock }; #endif [/src] [SRC locks.cpp] /**************************=-OpenDSA-=****************************** This file is a part of OpenDSA project(http://sourceforge.net/projects/opendsa) It can be destributed independently of OpenDSA with safe license of OpenDSA. OpenDSA is destributed by GPL license (04.06.2006). All rights reserved by (C) Konstantin Kaduk 2006. *******************************************************************/ #include "sem_lock.h" /****************************************************************** *******************************************************************/ c_lock::c_lock(int sem_id):s_set_id(0) { if(sem_id!=0) lock_init(sem_id); }; /****************************************************************** *******************************************************************/ c_lock::~c_lock() { int rc=semctl(s_set_id, 0, IPC_RMID); }; /****************************************************************** *******************************************************************/ int c_lock::lock_init(int sem_id) { printf("initing semaphore lock [%d]\n", sem_id); s_set_id = semget(sem_id, 3, IPC_CREAT | 0600); if(s_set_id==-1) { printf("Unable to allocate semaphore errno %d [%s]\n",errno, strerror(errno)); throw int(10); }; s_semun.array=&s_semarray[0]; s_semarray[0]=0; //reading s_semarray[1]=0; //writing s_semarray[2]=1; // spin lock rc = semctl(s_set_id, 3, SETALL, s_semun ); if(rc == -1) { printf("Problem to set sem value %d [%s]\n",errno, strerror(errno)); throw int(11); }; return 0; }; /****************************************************************** *******************************************************************/ void c_lock::stat( const char* f_comment) { s_semun.array=&s_semarray[0]; int rc = semctl(s_set_id, 0,GETALL, s_semun); if (f_comment!=NULL) printf("****** %s ******\n", f_comment); printf("SEM values READ WRITE WRSPIN\n"); printf(" [%d] [%d] [%d] \n", s_semarray[0], s_semarray[1], s_semarray[2]); printf("*********************************\n"); }; /****************************************************************** *******************************************************************/ void c_lock::r_lock() { struct sembuf sem_op; stat( "before read lock"); //increse for reading s_sem_op[0].sem_num = 0; s_sem_op[0].sem_op = 1; //increase read value s_sem_op[0].sem_flg = 0;//IPC_NOWAIT; //check for write s_sem_op[1].sem_num = 1; s_sem_op[1].sem_op = 0; // check for write s_sem_op[1].sem_flg = 0;//IPC_NOWAIT; rc=semop(s_set_id, &s_sem_op[0], 2); stat("read locked"); }; /****************************************************************** *******************************************************************/ void c_lock::r_unlock() { struct sembuf sem_op; stat("read unlocking"); s_sem_op[0].sem_num = 0; s_sem_op[0].sem_op = -1; //decrease reading value s_sem_op[0].sem_flg = 0; rc=semop(s_set_id, &s_sem_op[0], 1); stat(" read unlocked"); }; /****************************************************************** *******************************************************************/ void c_lock::w_lock() { stat("write locking"); //increse for read s_sem_op[0].sem_num = 0; s_sem_op[0].sem_op = 0; s_sem_op[0].sem_flg = 0;//IPC_NOWAIT; //check for write s_sem_op[1].sem_num = 1; s_sem_op[1].sem_op = 1; // check for write s_sem_op[1].sem_flg = 0;//IPC_NOWAIT; s_sem_op[2].sem_num = 2; s_sem_op[2].sem_op = -1; // set for exclusive s_sem_op[2].sem_flg = 0;//IPC_NOWAIT; rc=semop(s_set_id, &s_sem_op[0], 3); stat("write locked"); }; /****************************************************************** *******************************************************************/ void c_lock::w_unlock() { stat("write unlocking"); s_sem_op[1].sem_num = 1; s_sem_op[1].sem_op = -1; s_sem_op[1].sem_flg = 0; s_sem_op[2].sem_num = 2; s_sem_op[2].sem_op = 1; // check for spin write s_sem_op[2].sem_flg = 0;//IPC_NOWAIT; rc=semop(s_set_id, &s_sem_op[1], 2); stat("write unlocked"); }; [/SRC] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2007, 18:42 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005 пишет: > другие потоки могут обновлять контейнер. Самый дубовый случай запретить > доступ к контейнеру на время обхода его обхода и при обновлению. В > простейшем случаем можно использовать один мьютекс (или критическую > секцию). Может в моём случае это и прокатит, но, если размер контейнера Вот так и сделай, раз в что-то более сложное не врубаешься. Для начала сойдет. Если совсем будет туго, тогда будешь уже усовершенствованиями заниматься. > довольно большой эффективность видимо значительно снизится. Ничего , переживешь. Не миллионы же у тебя там. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2007, 10:27 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Что выросло, то выросло(с) Собственно на скрепке что получается, только я не отлаживал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.06.2007, 22:28 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
blindedЧто выросло, то выросло(с) Собственно на скрепке что получается, только я не отлаживал А в чём смысл константной функции-члена? Никогда с ними не сталкивался. void read_lock() const; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 10:55 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
blindedЧто выросло, то выросло(с) Собственно на скрепке что получается, только я не отлаживал Большое спасибо, за пример. Раньше не использовал семафоры. Попытаюсь разобраться. Только не совсем понятно почему не обойтись одним мьютексом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 11:30 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005Программа должна иметь возможность опрашивать несколько подсистем сбора данных. Пока я понимаю только вариант с запретом нескольких потоков одновременно обращаться к контейнеру с помощью мьютекса или критических секций. Но тогда при обходе контейнера не будет возможности обращаться к нему другим потоком. Хотя может быть по другому не сделаешь. В этом случае в контейнер могут писать несколько потоков.Варианты. 1) пайп 2) двойная буферизация 3) считывающий поток для обработки дублирует себе контейнер 4) пишущий поток может добавлять данные не по одному, а пачками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 12:19 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005 blindedЧто выросло, то выросло(с) Собственно на скрепке что получается, только я не отлаживал А в чём смысл константной функции-члена? Никогда с ними не сталкивался. void read_lock() const; Ну это-то понятно, обычно методы которые читают const и чтобы каждый раз не писать mutable на замке сделано const ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 12:20 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
maXmo OLEG_2005Программа должна иметь возможность опрашивать несколько подсистем сбора данных. Пока я понимаю только вариант с запретом нескольких потоков одновременно обращаться к контейнеру с помощью мьютекса или критических секций. Но тогда при обходе контейнера не будет возможности обращаться к нему другим потоком. Хотя может быть по другому не сделаешь. В этом случае в контейнер могут писать несколько потоков.Варианты. 1) пайп 2) двойная буферизация 3) считывающий поток для обработки дублирует себе контейнер 4) пишущий поток может добавлять данные не по одному, а пачками. А можно пояснить первые два вариант, что вы под ними подразумеваете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 14:56 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
1) как работает пайп: один поток туда пишет, другой читает и всё пучком. Недостаток – надо делать свой протокол :) По сути – нетипизированная потокобезопасная очередь. 2) что такое двойная буферизация: это использование двух буферов. Два контейнера – в один пишем (в одном потоке), из другого читаем (в другом), ждём, когда созреет второй контейнер, меняем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 16:45 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
в первом случае свой протокол надо делать если у тебя нефиксированный размер структуры или в чём ты там инфу передаёшь… ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 16:48 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
maXmo1) как работает пайп: один поток туда пишет, другой читает и всё пучком. Недостаток – надо делать свой протокол :) По сути – нетипизированная потокобезопасная очередь. Ну уж ежели делать то не pipe. а publish-subscribe. ээто когда специальный поток мультиплексирует входную очередь сообщений на множество потребителей. maXmo2) что такое двойная буферизация: это использование двух буферов. Два контейнера – в один пишем (в одном потоке), из другого читаем (в другом), ждём, когда созреет второй контейнер, меняем. Ну чего уж мелочитьсяю Пусть некоторый поток проецирует входные сообщения на модель и с некоторй частотой делает с этой модели мгновенную копию и публикует ее, все кому охота отображать - берет копию и чего-то с ней делает, потом хватает новую. Главное чтобы копия оставалась readonly ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.06.2007, 18:08 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
maXmo1) как работает пайп: один поток туда пишет, другой читает и всё пучком. Недостаток – надо делать свой протокол :) По сути – нетипизированная потокобезопасная очередь. 2) что такое двойная буферизация: это использование двух буферов. Два контейнера – в один пишем (в одном потоке), из другого читаем (в другом), ждём, когда созреет второй контейнер, меняем. Все-таки не понятно насчёт пайпа. Один поток пишет в контейнер, другой читает. Т.е. читающие или пишуще потоки монопольно захватывают контейнер или в чём фокус? А в методе двойной буферизации надо как заполняются буфера для записи и для чтения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2007, 10:08 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005Все-таки не понятно насчёт пайпа. Один поток пишет в контейнер, другой читает. Т.е. читающие или пишуще потоки монопольно захватывают контейнер или в чём фокус?операционная система прозрачно синхронизирует доступ или вообще всё может параллельно происходить. OLEG_2005А в методе двойной буферизации надо как заполняются буфера для записи и для чтения?буфер заполняется как обычно, как ты их там заполняешь? Методом add наверно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.06.2007, 21:56 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
_maXmo OLEG_2005Все-таки не понятно насчёт пайпа. Один поток пишет в контейнер, другой читает. Т.е. читающие или пишуще потоки монопольно захватывают контейнер или в чём фокус?операционная система прозрачно синхронизирует доступ или вообще всё может параллельно происходить. OLEG_2005А в методе двойной буферизации надо как заполняются буфера для записи и для чтения?буфер заполняется как обычно, как ты их там заполняешь? Методом add наверно. Как добиться идентичности данных в буфере для записи и для чтения? И что даёт наличие двух буферов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2007, 08:38 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005 Все-таки не понятно насчёт пайпа. Один поток пишет в контейнер, другой читает. Т.е. читающие или пишуще потоки монопольно захватывают контейнер или в чём фокус? А в методе двойной буферизации надо как заполняются буфера для записи и для чтения? Ответ на вопрос что использовать лучше можно дать только после того как выяснится: 1. Среднее количество обращений( на чтение и изменение) к одному элементу контейнера за весь цикл обработки. 2. Логическая зависимось элементов между собой. 3. Влияние изменения значения конкретного элемента на конечный результат. Еще как вариант к рассмотрению , можно разбить контейнер на несколько, каждый из которых будет обрабатываться одной нитью, при необходимости получения доступа к элементу из другой нити, нить хозяйка будет выдавать доступ через указатель(ссылку) или делать копию, учитывая это при собственных вычислениях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2007, 10:22 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
onstat- OLEG_2005 Все-таки не понятно насчёт пайпа. Один поток пишет в контейнер, другой читает. Т.е. читающие или пишуще потоки монопольно захватывают контейнер или в чём фокус? А в методе двойной буферизации надо как заполняются буфера для записи и для чтения? Ответ на вопрос что использовать лучше можно дать только после того как выяснится: 1. Среднее количество обращений( на чтение и изменение) к одному элементу контейнера за весь цикл обработки. 2. Логическая зависимось элементов между собой. 3. Влияние изменения значения конкретного элемента на конечный результат. Еще как вариант к рассмотрению , можно разбить контейнер на несколько, каждый из которых будет обрабатываться одной нитью, при необходимости получения доступа к элементу из другой нити, нить хозяйка будет выдавать доступ через указатель(ссылку) или делать копию, учитывая это при собственных вычислениях. Непонятно, что вы подразумеваете под пунктом 3. А среднее количество обращения определить трудно, так как будет зависеть от загрузки программы (количества клиентских программ, которым выдаются данные и количеств опрашиваемых подсистем съёма данных). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2007, 14:27 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005Как добиться идентичности данных в буфере для записи и для чтения?что запишешь, то и будет прочитано, или тебе что-то другое надо… Расскажи-ка получше про необходимость идентичности. Что ты хотел этим сказать? OLEG_2005И что даёт наличие двух буферов?потокобезопасность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2007, 14:51 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
а то молчишь как на допросе в ЦРУ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2007, 14:53 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
maXmo OLEG_2005Как добиться идентичности данных в буфере для записи и для чтения?что запишешь, то и будет прочитано, или тебе что-то другое надо… Расскажи-ка получше про необходимость идентичности. Что ты хотел этим сказать? OLEG_2005И что даёт наличие двух буферов?потокобезопасность. Я просто не понял идею с двум буферами. Есть контейнер, который разные потоки могут читать и могут писать в него. Что вы имели в виду, говоря о буфере для записи и для чтения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2007, 15:23 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005 А среднее количество обращения определить трудно, так как будет зависеть от загрузки программы (количества клиентских программ, которым выдаются данные и количеств опрашиваемых подсистем съёма данных). С этого места пожалуйста поподробнее. Есть у меня подозрение, что во время написания вы сами поймете что имелось ввиду под п3. А может все данные можно положить в таблицы СУБД и не париться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2007, 15:25 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
onstat- OLEG_2005 А среднее количество обращения определить трудно, так как будет зависеть от загрузки программы (количества клиентских программ, которым выдаются данные и количеств опрашиваемых подсистем съёма данных). С этого места пожалуйста поподробнее. Можете начать с того какая прикладная(логическая) сущность будет храниться в качестве ключа Вашего map. А может map выбран только как автоматический сортировщик. И вы собираетесь за каждой итераций проходиться по нему полностью? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2007, 15:33 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005Я просто не понял идею с двум буферами. Есть контейнер, который разные потоки могут читать и могут писать в него. Что вы имели в виду, говоря о буфере для записи и для чтения.сейчас ты используешь один контейнер = один буфер, из чего логично возникает проблема синхронизации, если использовать два буфера (по одному на поток) и синхронизировать только их обмен по некоторому критерию, проблема слабеет. Или ещё подробнее рассказывать? молчит, гирой… ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2007, 16:32 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
onstat-А может map выбран только как автоматический сортировщик. И вы собираетесь за каждой итераций проходиться по нему полностью?возможно, он их периодически перебирает на предмет изменений и на изменения реагирует??? хз… ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2007, 16:33 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
maXmo хз… Дествительно хз. В этом случае изменения лучше указатели на измененные обьекты хранить в отдельном list, map | vector. А в основном map хранить ключ быстрого поиска и указатель на обьект. Хотя могут быть варианты с п.3, если это влияние существенно и при изменении нужно пробежаться по всем обьектам снова. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.06.2007, 17:05 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
onstat- OLEG_2005 А среднее количество обращения определить трудно, так как будет зависеть от загрузки программы (количества клиентских программ, которым выдаются данные и количеств опрашиваемых подсистем съёма данных). С этого места пожалуйста поподробнее. Есть у меня подозрение, что во время написания вы сами поймете что имелось ввиду под п3. А может все данные можно положить в таблицы СУБД и не париться. Сразу писать в таблицы СУБД нельзя. В контейнере у меня хранятся значения аналоговых и дискретных сигналов, которые я получаю от подсистемы сбора данных. Периодическия по данным контейнера я выполняю расчёт и помещаю их в БД (архивирую данные). В контейнере хранятся текущие данные аналоговых и дискретных данных, их также нужно выдавать клиентским программам, например программе рабочего места диспетчера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2007, 08:41 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
onstat- onstat- OLEG_2005 А среднее количество обращения определить трудно, так как будет зависеть от загрузки программы (количества клиентских программ, которым выдаются данные и количеств опрашиваемых подсистем съёма данных). С этого места пожалуйста поподробнее. Можете начать с того какая прикладная(логическая) сущность будет храниться в качестве ключа Вашего map. А может map выбран только как автоматический сортировщик. И вы собираетесь за каждой итераций проходиться по нему полностью? Для хранения текуших данны у меня два контейнера map. Один для хранения текущих аналоговых данных, другой для хранения текущих дискретных данных. В качестве ключа в обоих случаях выступает идентификатор входа (целочисленное значение), ну а данные - значения сигналов, признак достоверности и т.д. Когда данные получаю от подсистемы сбора данных, я обновляю эемент контейнера map примерно так currentTi[id] = data. Так как поиск в контейнере map пропопрционален log числа элементов, то данная оперция должна выполняться достаточно быстро. Вот доступ к этому контейнеру и надо синхронизировать. В нему могут обращаться и потоки приёма данных от подсистемы сбора данных, поток, выполняющий архивирование - периодический расчёт средних значений ТИ и запись их в БД, потоки выдачи данных клиентским программам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2007, 08:50 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
maXmo OLEG_2005Я просто не понял идею с двум буферами. Есть контейнер, который разные потоки могут читать и могут писать в него. Что вы имели в виду, говоря о буфере для записи и для чтения.сейчас ты используешь один контейнер = один буфер, из чего логично возникает проблема синхронизации, если использовать два буфера (по одному на поток) и синхронизировать только их обмен по некоторому критерию, проблема слабеет. Или ещё подробнее рассказывать? молчит, гирой… Хорошо было бы ещё подробнее. Непонятно, как в моём случае два буфера решат проблему. Непонятно, какие потоки с какими буферами работают и как происходит обмен информации между буферами, копирование информации из одного буфера в другой довольно трудоёмкая операция или я неправ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2007, 08:55 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
onstat- maXmo хз… Дествительно хз. В этом случае изменения лучше указатели на измененные обьекты хранить в отдельном list, map | vector. А в основном map хранить ключ быстрого поиска и указатель на обьект. Хотя могут быть варианты с п.3, если это влияние существенно и при изменении нужно пробежаться по всем обьектам снова. А насколько просто хранить указатели в контейнерах stl? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2007, 10:45 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
И ещё интересно, как обычно поступают для создания потоконезависимых контейнеров данных: инкапсулируют синхронизацию на уровне объекта или класс не делают потоконезависимым, а объекты, которые используют данные хранилища, ответственны за синхронизацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2007, 16:18 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
И ещё интересно, как обычно поступают для создания потоконезависимых контейнеров данных: инкапсулируют синхронизацию на уровне объекта или класс не делают потоконезависимым, а объекты, которые используют данные хранилища, ответственны за синхронизацию? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.06.2007, 16:19 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005Когда данные получаю от подсистемы сбора данных, я обновляю эемент контейнера map примерно так currentTi[id] = data.мне представляется, что на первой итерации ты заполнишь свой контейнер и далее число элементов в нём увеличиваться не будет совсем или крайне редко. Не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.06.2007, 11:41 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
maXmo OLEG_2005Когда данные получаю от подсистемы сбора данных, я обновляю эемент контейнера map примерно так currentTi[id] = data.мне представляется, что на первой итерации ты заполнишь свой контейнер и далее число элементов в нём увеличиваться не будет совсем или крайне редко. Не так? Да. Из базы я считываю список аналоговых и дискретных сигналов, которые будут обновляться от подсистемы сбора данных. Во время работы происходит изменения значений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2007, 09:04 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
и чего тогда синхронизовать, если контейнер практически никогда не меняется? Вот если ты боишься, что данные обновляешь как-то неатомарно… тут надо смотреть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2007, 15:02 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
maXmoи чего тогда синхронизовать, если контейнер практически никогда не меняется? Вот если ты боишься, что данные обновляешь как-то неатомарно… тут надо смотреть. Проблема в том, что несколько потоков могут одновременно изменять данные и читать. Некоторые потоки периодически обходят контейнеры, выполняя расчёты, выдавая данные, другие получив данные из сети обновляют данные контейнеров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2007, 15:18 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Как лучше синхронизировать доступ к контейнеру, инкапсулировать синхронизацию в классе котнейнера или отдать синхронизацию на откуп классам использущим эти контейнеры? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2007, 15:23 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
Можно пояснить идею с двумя буферами? Не понятен суть метода. Есть потоки, которые обходят весь контейнер периодически, не очень здорово, если во вреямя обхода доступ к контейнеру заблокируется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2007, 15:28 |
|
||
|
контейнеры STL и многопоточность
|
|||
|---|---|---|---|
|
#18+
OLEG_2005Проблема в том, что несколько потоков могут одновременно изменять данные и читать. Некоторые потоки периодически обходят контейнеры, выполняя расчёты, выдавая данные, другие получив данные из сети обновляют данные контейнеров.видишь ли, контейнер к этому уже отношения не имеет, т.к. он не будет твоему коду мешать работать, и если твой код требует какой-то синхронизации, тебе следует это требование сформулировать и реализовать и тип синхронизации будет полностью зависеть от этих требований. OLEG_2005Можно пояснить идею с двумя буферами?можно, если скажешь, что пояснять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.06.2007, 16:31 |
|
||
|
контейнеры 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?all=1&fid=57&tid=2028679]: |
0ms |
get settings: |
10ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
157ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
116ms |
get tp. blocked users: |
2ms |
| others: | 241ms |
| total: | 563ms |

| 0 / 0 |
