Parallel while loop dequeue

[mperlick777]

I have three parallel while loops with queuing. Every second I enqueue the loop count. When I dequeue the value in the bottom loop I only see every even number when I monitor the element with a debug probe. Why wouldn't I see every value?

Thank you.

[billko]

---

@mperlick777 wrote:

I have three parallel while loops with queuing. Every second I enqueue the loop count. When I dequeue the value in the bottom loop I only see every even number when I monitor the element with a debug probe. Why wouldn't I see every value?

Thank you.

---

You can't dequeue a que in two places.  Whoever wins the race will get to dequeue the data.  Everyone else loses.

While you're at it, you can delete that sequence structure.  All it's doing is giving me heartburn.  😉

[0utlaw]

Hello mperlick777,

As you noted, you have two loops dequeueing elements from a single queue.  Based on the behavior you've observed, it sounds like your consumer loops are each pulling out every other element sent by your producer.

Once you dequeue an element, it's no longer available for other dequeue operations.  Multiple-reader architectures are usually used with queues when you're trying to parallelize processing of data and each element can be operated on without affecting others.

If you're looking for a way to broadcast messages to multiple locations, I suggest you take a look at Notifiers.

Best Regards,

[mperlick777]

Thank you Tom. Now I see what's happening. I'll need to look into notifiers so both consumer loops will be triggered with the same message.

[RavensFan]

But if you need all pieces of data to go to all loops, you will still need to use queues.  (Notifiers are only good for holding 1 piece of data.)  You just need to have 1 queue created for each of your consumer loops, and enqueue the same data in all of the queues.

[JÞB]

Notifiers dequeue the latest element arriving on the queue.  Notifiers hold timestamp information within the wait on notifier and all waits on the same notifiers may each recieve the same notification.   This is different from queues and is what makes the Notifier more suitable for one-to-many interprocess communications.

The down side of notifiers is that they can be "Lossey"  they can only recieve the latest Notification (With starting exceptions) so if the producer is enqueueing "commands" that can be a problem- with "Data" its a question of design and with "State" it is no problem.

 Without seeing you implementation it is hard to advise you.  But, if you draw out your communications map, and it has a lot of crossed wires- you probably have enough information to revise it and avoid problems.

[mperlick777]

I see the only downside with notifiers is that I may miss one if a vi doesn't finish before it recieves the next notifier. I may need to have two queues to make this work. The sample code I sent was a pared down version of the code I'm running to allow others to run it. The second loop in my actual app might not finish in time to receive the notifier.

[JÞB]

If the data transfered must be "lossless" a notifier is not the right answer.  If the transfer is one-to-many a queue is not the right answer.

"Lossless" "one-to-many" solutions require multiple queues (or some roll-your-own pseudo buffer but that is usually not needed)

[billko]

If it helps, you can bundle all your queue refs together.

[altenbach]

I don't uderstand why there are three loops.

Use one queue and only two loops. Keep the producer loop, but combine the code of the two consumer loop into one. Place the code of the current third loop inside a case structure that turns to a blank state after a certain number of iterations to duplicate the current functionality.

Also clean up the code so it can be shutdown in a reasonable way. Currently it can only be aborted.