Организация очередей при параллельных циклах

[Sergey Puzanov]

Добрый день. Вопрос про структуру кода и передачу данных. Имеется 5 параллельных циклов: обработка пользовательских событий, UI, приём данных с аппаратуры, передача по сети и запись в файл. Для инициализации модулей нужно передавать данные из 2 цикла в 3 цикл, для передачи и записи из 3 в 4 и 5 соответственно. Для этого нужно класть в соответствующую очередь событие + необходимые данные. Отсюда вопрос - является ли нормальным паттерном вызов из любого цикла события для любой другой очереди, или есть какое-то более изящное решение и контроль всех очередей в одном цикле? Спасибо.

[rushonda]

есть библиотека Tasking2. Тут на форуме можно скачать где-то. Мне понравилась - там все основные механизмы взаимодействия для начала есть. Есть тема с проектом на ее основе: viewtopic.php?p=71086#p71086.
Конечно все зависит от масштаба проекта. Можно для небольшого проекта посмотреть на JKI State Machine - тоже удобная штука.

[jane_wild]

Actor Framework вот тема, она мне достаточно сильно помогла, ей правда уже лет 8, но приципы то не изменились. Так вот там taras_33 пытался на примерах рассказать что это такое.

[Sergey Puzanov]

Спасибо, изучу, надеюсь не сильно долго будет переходить на эту модель, если там всё более структурировано, нежели при очередях

[Artem.spb]

Спасибо, изучу, надеюсь не сильно долго будет переходить на эту модель, если там всё более структурировано, нежели при очередях

Ну Акторы - это надстройка надстройка над очередями, так что структурированность зависит от программиста, а не от шаблона
А в целом разумно делать так чтобы разные части проекта как можно меньше знали друг о друге.
Но это в идеальном и большом проекте с прицелом на изменения.
Например, цикл чтения с оборудования не должен знать кто, что и как пишет в какой-то файл. Его задача считать значения и отправить дальше. В обратную сторону так же.
В этом случае каждый участок проекта можно относительно просто модифицировать (например, изменив тип оборудования), без поиска зависимостей по всему коду.
Но всегда стоит вопрос сроков, масштабов проекта и задач.
Что по мне, так акторы - не самая разумная идея для начала изучения , есть риск запутаться

[Sergey Puzanov]

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

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

Что по мне, так акторы - не самая разумная идея для начала изучения , есть риск запутаться

Хочется верить,что после 3 лет работы уже не совсем начало изучения идёт, но с каждым вопросом на форуме всё больше становиться понятно, что есть куда стремиться.

[ladik]

Посмотрите ещё в сторону Workers. Попроще чем Акторы в освоении, но тоже весьма удобная штуковина.