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

ConcurrentDictionary<subsriptionKey, ImmutableList<UserInfo>>

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

Методы подписки/отписки должны вызываться потокобезопасно.
Есть ли готовые реализации для решения данной проблемы?

Здравствуйте, Goldy, Вы писали:

G>Здрастувуйте,
G>Есть следующая задача:
G>Пользователям нужно работать с подписками на потоки данных (подписаться/отписаться), при этом если параметры подписки совпадают то подписка должна шариться между пользователями.
G>Что то вроде:
G>

G>ConcurrentDictionary<subsriptionKey, ImmutableList<UserInfo>>
G>

G>При этом должны выполняться следующие условия:
G> — при первой подписке (subsriptionKey нет в словаре) должен вызываться пользовательский метод Action который осуществляет реальный вызов подписки на удаленном сервере, пользователь добавляется в список подписчиков
G> — при приходе данных от сервера по ключу из словаря выбираем всех подписанных пользователей и отсылаем им данные
G> — все последующие подписки просто добавляют пользователя в список (пользователи могут дублироваться — один пользователь может несколько раз запрашивать подписку с одинаковыми параметрами, при этом он должен столько же раз отписаться)
G> — при отписке соответствующий пользователь удаляется из списка подписчиков с заданным колючем подписки, при этом если список пользователь пустой, то должен вызываться пользовательский метод Action который осуществляет реальный вызов отписки на удаленном сервере, и данный ключ подписки удаляется из словаря.

G>Методы подписки/отписки должны вызываться потокобезопасно.
G>Есть ли готовые реализации для решения данной проблемы?


Идея использовать ConcurrentDictionary неплохая. Но вот тут:

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

без дополнительных локов не обойтись, кмк.

Здравствуйте, Sharov, Вы писали:

S>без дополнительных локов не обойтись, кмк.

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

Здравствуйте, Goldy, Вы писали:

G>Это понятно — поэтому и спрашиваю может уже есть готовые реализации (желательно с меньшим временем локов, так как запросов будет много), не хочется велосипед изобретать.

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

Здравствуйте, TK, Вы писали:

TK>сделайте выделенный тред который по свистку будет заниматься подпиской/отпиской потребителей. сама же подписка/отписка будет выглядеть как добавиться/удалится из списка и выставить событие на обновление статуса.

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