11-22-2024 01:58 AM
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!
11-22-2024 03:26 AM
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.
11-22-2024 04:16 AM
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.
11-22-2024 05:05 AM - edited 11-22-2024 05:14 AM
@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.
11-22-2024 06:41 AM
@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.