_maXmo OLEG_2005Все-таки не понятно насчёт пайпа. Один поток пишет в контейнер, другой читает. Т.е. читающие или пишуще потоки монопольно захватывают контейнер или в чём фокус?операционная система прозрачно синхронизирует доступ или вообще всё может параллельно происходить.
OLEG_2005А в методе двойной буферизации надо как заполняются буфера для записи и для чтения?буфер заполняется как обычно, как ты их там заполняешь? Методом add наверно.

Как добиться идентичности данных в буфере для записи и для чтения? И что даёт наличие двух буферов?

onstat- OLEG_2005
Все-таки не понятно насчёт пайпа. Один поток пишет в контейнер, другой читает. Т.е. читающие или пишуще потоки монопольно захватывают контейнер или в чём фокус?
А в методе двойной буферизации надо как заполняются буфера для записи и для чтения?

Ответ на вопрос что использовать лучше можно дать только после того как
выяснится:

1. Среднее количество обращений( на чтение и изменение) к одному элементу
контейнера за весь цикл обработки.
2. Логическая зависимось элементов между собой.
3. Влияние изменения значения конкретного элемента на конечный результат.



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

Непонятно, что вы подразумеваете под пунктом 3. А среднее количество обращения определить трудно, так как будет зависеть от загрузки программы (количества клиентских программ, которым выдаются данные и количеств опрашиваемых подсистем съёма данных).

maXmo OLEG_2005Как добиться идентичности данных в буфере для записи и для чтения?что запишешь, то и будет прочитано, или тебе что-то другое надо… Расскажи-ка получше про необходимость идентичности. Что ты хотел этим сказать?

OLEG_2005И что даёт наличие двух буферов?потокобезопасность.

Я просто не понял идею с двум буферами. Есть контейнер, который разные потоки могут читать и могут писать в него. Что вы имели в виду, говоря о буфере для записи и для чтения.

onstat- OLEG_2005
А среднее количество обращения определить трудно, так как будет зависеть от загрузки программы (количества клиентских программ, которым выдаются данные и количеств опрашиваемых подсистем съёма данных).

С этого места пожалуйста поподробнее.
Есть у меня подозрение, что во время написания вы сами поймете что имелось ввиду под п3.

А может все данные можно положить в таблицы СУБД и не париться.

Сразу писать в таблицы СУБД нельзя. В контейнере у меня хранятся значения аналоговых и дискретных сигналов, которые я получаю от подсистемы сбора данных. Периодическия по данным контейнера я выполняю расчёт и помещаю их в БД (архивирую данные). В контейнере хранятся текущие данные аналоговых и дискретных данных, их также нужно выдавать клиентским программам, например программе рабочего места диспетчера.

onstat- onstat- OLEG_2005
А среднее количество обращения определить трудно, так как будет зависеть от загрузки программы (количества клиентских программ, которым выдаются данные и количеств опрашиваемых подсистем съёма данных).

С этого места пожалуйста поподробнее.


Можете начать с того какая прикладная(логическая) сущность будет
храниться в качестве ключа Вашего map.

А может map выбран только как автоматический сортировщик.
И вы собираетесь за каждой итераций проходиться по нему полностью?

Для хранения текуших данны у меня два контейнера map. Один для хранения текущих аналоговых данных, другой для хранения текущих дискретных данных. В качестве ключа в обоих случаях выступает идентификатор входа (целочисленное значение), ну а данные - значения сигналов, признак достоверности и т.д. Когда данные получаю от подсистемы сбора данных, я обновляю эемент контейнера map примерно так currentTi[id] = data. Так как поиск в контейнере map пропопрционален log числа элементов, то данная оперция должна выполняться достаточно быстро. Вот доступ к этому контейнеру и надо синхронизировать. В нему могут обращаться и потоки приёма данных от подсистемы сбора данных, поток, выполняющий архивирование - периодический расчёт средних значений ТИ и запись их в БД, потоки выдачи данных клиентским программам.

maXmo OLEG_2005Я просто не понял идею с двум буферами. Есть контейнер, который разные потоки могут читать и могут писать в него. Что вы имели в виду, говоря о буфере для записи и для чтения.сейчас ты используешь один контейнер = один буфер, из чего логично возникает проблема синхронизации, если использовать два буфера (по одному на поток) и синхронизировать только их обмен по некоторому критерию, проблема слабеет. Или ещё подробнее рассказывать?

молчит, гирой…

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

onstat- maXmo
хз…


Дествительно хз.

В этом случае изменения лучше указатели на измененные обьекты хранить в отдельном
list, map | vector.
А в основном map хранить ключ быстрого поиска и указатель на обьект.

Хотя могут быть варианты с п.3, если это влияние существенно и при изменении
нужно пробежаться по всем обьектам снова.

А насколько просто хранить указатели в контейнерах stl?

И ещё интересно, как обычно поступают для создания потоконезависимых контейнеров данных: инкапсулируют синхронизацию на уровне объекта или класс не делают потоконезависимым, а объекты, которые используют данные хранилища, ответственны за синхронизацию.

И ещё интересно, как обычно поступают для создания потоконезависимых контейнеров данных: инкапсулируют синхронизацию на уровне объекта или класс не делают потоконезависимым, а объекты, которые используют данные хранилища, ответственны за синхронизацию?

maXmo OLEG_2005Когда данные получаю от подсистемы сбора данных, я обновляю эемент контейнера map примерно так currentTi[id] = data.мне представляется, что на первой итерации ты заполнишь свой контейнер и далее число элементов в нём увеличиваться не будет совсем или крайне редко. Не так?

Да. Из базы я считываю список аналоговых и дискретных сигналов, которые будут обновляться от подсистемы сбора данных. Во время работы происходит изменения значений.

maXmoи чего тогда синхронизовать, если контейнер практически никогда не меняется? Вот если ты боишься, что данные обновляешь как-то неатомарно… тут надо смотреть.

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

Как лучше синхронизировать доступ к контейнеру, инкапсулировать синхронизацию в классе котнейнера или отдать синхронизацию на откуп классам использущим эти контейнеры?

Можно пояснить идею с двумя буферами? Не понятен суть метода. Есть потоки, которые обходят весь контейнер периодически, не очень здорово, если во вреямя обхода доступ к контейнеру заблокируется?