Является ли мой дизайн для отправки данных клиентам через различные промежутки времени правильным?

Question

Код должен быть написан на C ++.Я упоминаю об этом на всякий случай, если кто-то предложит решение, которое не будет работать эффективно при реализации в C ++.

Цель:

Производитель, работающий в потоке t1 вставляет изображения в получателя, который работает в потоке t2.У потребителя есть список клиентов, которым он должен отправлять изображения с различными интервалами.Например, для client1 требуются изображения каждые 1 с, для client2 требуются изображения каждые 5 с и т. Д.

Предлагаемая реализация:

В приемнике есть одна основная очередь imagesQ, в которую производитель ставит очередьизображения к.В дополнение к основной очереди Потребитель управляет списком векторов очередей размером clientImageQs в виде числа клиентов.Потребитель создает для каждого клиента подпотребителя, который работает в своем собственном потоке.Каждый такой субпотребитель вытесняет изображения из соответствующей очереди из clientImageQs и отправляет изображения своему клиенту с интервалом.

Каждый раз, когда новое изображение поступает в imagesQ, Потребитель дублирует его и ставит в очередькаждая очередь в clientImageQs.Таким образом, каждый субпотребитель сможет отправлять изображения своему клиенту на своей частоте.

Потенциальная проблема и решение:

Если производитель производит многократное добавление изображений в очередьчем выше скорость, чем у одного из потребителей, то очередь взорвется.Но Потребитель может проверить размер очереди в clientImageQs перед постановкой в ​​очередь.И, если необходимо, Потребитель снимет несколько старых изображений перед тем, как ставить новые.

Вопрос

Это хороший дизайн или есть лучший?

Answer 1

Вы описываете проблему в рамках набора уже определенных ограничений решения.Ваше описание сложное, запутанное, и, смею сказать, запутанное.Почему потребитель, который только распространяет изображения из общего буфера?Почему бы не позволить каждому «клиенту», как вы его называете, читать из буфера так, как нужно?Почему бы не реализовать общий буфер как буфер для одного изображения.Производитель пишет по его ставке.Клиенты выполняют неразрушающие чтения из буфера по собственному желанию.Каждый клиент гарантированно считывает самое последнее изображение в буфере всякий раз, когда клиент читает буфер.Производитель просто перезаписывает буфер при каждой записи.Многоэлементная очередь не дает никаких преимуществ в этом приложении.На самом деле, как вы описали, это значительно усложняет решение.См. http://sworthodoxy.blogspot.com/2015/05/shared-resource-design-patterns.html Найдите заголовок «Безусловный буфер».Приведенные выше примеры в публикации публикуются с использованием Ada, но концепции, относящиеся к параллельным шаблонам проектирования, применимы ко всем языкам программирования, поддерживающим параллелизм.