LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Parallel while loop dequeue

The original requirement was that both consumers see all values, which is an impossibility with one queue. If you don’t care which consumer sees which value but just want to make sure each value is consumed exactly once, the queue is the perfect solution. And LabVIEW takes care that the concurrent queue accesses are properly synchronized that they won’t crash, There were a few windows of opportunity for multiple parallel queue reads from different places  to crash LabVIEW when queues were introduced originally, but that’s some 25 years ago!

Rolf Kalbermatter
My Blog
0 Kudos
Message 21 of 25
(86 Views)

Note: there is an example for "Worker Pool", with order preservation, inside Messenger Library.  It is using Messenger Library "QueueMessengers" and "Future Tokens", but both these are wrappings of basic LabVIEW Queues (a Future Token is a single-element temporary Queue that can only be written once and read once), so one can easily do this without Messenger Library.

drjdpowell_0-1732267433281.png

 

0 Kudos
Message 22 of 25
(75 Views)

The only caveat with multiple dequeues is that only 1 will get the message. If you for some reason want to send to all queues (e.g. quit) i guess you have to requeue the message or something. That's not really a problem if the consumers stops, but if they're supposed to continue and not wait i guess it can be a bit messy. 

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 23 of 25
(68 Views)

@Yamaeda wrote:

The only caveat with multiple dequeues is that only 1 will get the message. If you for some reason want to send to all queues (e.g. quit) i guess you have to requeue the message or something.  


You can see that in the example I posted; I sent "Shutdown" 4 times for my 4 workers.  Only works on Quit, though, as otherwise one Worker might take multiple copies of the message.  Combining "Work Queue" (one worker gets each message) with "Message Queue" (every one gets the same message) is tricky, and it is probably best to have simple workers that just do work.

0 Kudos
Message 24 of 25
(61 Views)

@drjdpowell wrote:

@Yamaeda wrote:

The only caveat with multiple dequeues is that only 1 will get the message. If you for some reason want to send to all queues (e.g. quit) i guess you have to requeue the message or something.  


You can see that in the example I posted; I sent "Shutdown" 4 times for my 4 workers.  Only works on Quit, though, as otherwise one Worker might take multiple copies of the message.  Combining "Work Queue" (one worker gets each message) with "Message Queue" (every one gets the same message) is tricky, and it is probably best to have simple workers that just do work.


I had to do some experiments. 🙂 Only the 1st one feels like a serious solution.

 

Continue can e.g. be achieved with a Rendevous in that case waiting for the others, adding some counter to the message letting them requeue while counting down (not a guarantee if someone is already performing a long action), adding an "id" or status to the message which gets requeued until it lands in the right consumer when can then send to the next one in the same manner. 

 

 

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 25 of 25
(47 Views)