Посоветуйте реализацию "один писатель/много читателей"

[AlexCasual]

Посоветуйте пожалуйста реализацию многопоточного паттерна "один писатель/много читателей" с наибольшей скоростью работы.
Ставка делается именно на скорость работы.

[RXL]

Что ты имеешь в виду здесь под скоростью? Минимальное время реакции? Немного поконкретнее.

[Dimka]

AlexCasual, ерунда какая-то. Скорость работы (как пропускная способность системы - количество операций в единицу времени) целиком зависит от метода решения - т.е. от того факта, что доступ реализован как "один писатель и много читателей", а не каким-то другим способом.

[AlexCasual]

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

[Finch]

Перед началом записи, пошли сигнал всем читателям, что регион записей от А до Б не актуален. Когда закончиш писать, что весь регион актуален. А читатели уже сами будут разбираться. Подождать или читать только доступный регион. Как послать сигнал, все зависит от структуры данных Даже может быть просто метка на каждую строку записи, об ее актуальности.

[Dimka]

AlexCasual, ты говоришь такие вещи, которые разбираются в самом шаблоне. Может тогда с шаблоном лучше "тщательнее" познакомиться?

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

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

Finch правильно предложил, что блокировке подвергаться может не весь ресурс, а лишь какая-то его часть. Это уменьшает количество блокировок.

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

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

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

Вообще на зримом примере столовой и уборщицы можно массу стратегий придумать. Но это уже стратегии управления выделением ресурса, а не шаблон "читатели-писатель".

[RXL]

Создать элемент очереди, заблокировать всю очередь, добавить элемент в очередь, снять блокировку. Быстрее не получится. Выбрать также быстро, особенно если не использовать фильтров. С фильтрами немного медленнее и все зависит от алгоритма и глубины очереди.

Как вариант, читатель может быть совмещен с диспетчером пула потоков: это даст меньше участников блокировок, функции потока не нужно будет работать с очередью.