Очереди можно использовать «неправильно»
Мы же знаем, что очередь — это «первый пришёл — первый ушёл» (FIFO), и есть строгое правило: один или несколько производителей → один (и только один) потребитель. Это связано с тем, что при чтении элемента он удаляется из очереди, поэтому последующие попытки чтения будут неудачными. Возможно ли использовать очередь в сценарии одного производителя → множества потребителей?
Несколько лет назад у нас была задача распараллелить ресурсоёмкие вычисления: АЦП получал данные, которые нужно было прогнать через сложные алгоритмы. Был многопроцессорный серверный ПК, CPU был загружен на несколько процентов, но вычисления всё равно отставали и система не справлялась с потоком данным. Проблема была в том, что вычисления не были параллельными.
Несколько параллельных циклов решали проблему параллельности, но как организовать распределение задач? Как producer должен понять, в какую очередь отправить новую порцию данных? Флаги, обратная связь «я завершил вычисления»? Новые усложнения архитектуры. фуфуфу.
В итоге мы нашли элегантное решение. Каждый элемент из очереди можно забрать ровно один раз. Именно это нам и нужно! Один производитель и много потребителей. Как только один из экземпляров обработчика завершает очередной цикл, он встаёт в очередь на… чтение очереди.
По сути LabVIEW за нас занималось диспетчеризацией потоков.
В простом варианте это просто N параллельных циклов/SubVI. Если хочется чуть больше универсальности и привязать количество циклов к количеству процессоров, то можно запускать вычислители с помощью call-by-ref.
Так что, как говорили у нас в школе: если нельзя, но очень хочется, то можно.
.
