Parallel while loop dequeue

[mperlick777]

I was actually thinking the same thing. All I really need are two loops and put the code of the third loop in the producer loop. I know the code's a bit messy now with no method of stopping one loop, but this is just a prototype for trying out queuing. The second loop sends out CAN data that's synchronized with the GPS data.

[crossrulz]

---

Jeff·Þ·Bohrer wrote:

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

---

Or User Events!  But probably not the best route for this.

Reevaluating what should be in separate loops is probably the easiest way to fix this.  After that, use multiple queues.

[joshua.l.guthrie2.civ]

Instead of making a new thread, figured I'd use this thread as it's the same topic.  If nothing else, it may help complete the discussion.

I have an application where I send commands from a producer to a que and execute them in a consumer.  A que message handler. 

• Execution times are wildly different.  Some execution times are painfully slow.
• I don't care what order they get executed in
• Would love to start executing the next command while I'm waiting on a slow one to complete.

In this case, wouldn't parallel deque elements work fine?

From reading the thread, one would get the opinion that parallel deque's are a no-no no matter what.  Am I missing something?

Thanks!

-josh

[Yamaeda]

It sounds like you want User Events instead.

[mcduff]

---

@joshua.l.guthrie2.civ wrote:

• I don't care what order they get executed in

In this case, wouldn't parallel deque elements work fine?

---

I have used parallel dequeue for processing data to a file. For that case order did not matter. As long as order does not matter and commands can be dequeued without knowing past "history", parallel dequeue could work.

[drjdpowell]

Parallel dequeuing is called the "Worker Pool" pattern, and can indeed be done with LabVIEW Queues (though not User Events).  You can even do it if the order matters, but that is extra work to reassemble the order.

[crossrulz]

---

@joshua.l.guthrie2.civ wrote:

From reading the thread, one would get the opinion that parallel deque's are a no-no no matter what.  Am I missing something?

---

Do not follow dogmas. There are times where using multiple loops to process data from the same queue do make sense. However, you will have additional complexity as you now have to be more careful in how the loops are commanded to stop, how the queue is managed (have make sure all of the loops are stopped before releasing the queue), etc.

[joshua.l.guthrie2.civ]

---

@Yamaeda wrote:

It sounds like you want User Events instead.

---

I think I mis-represented the problem a bit.  I have a central computer that houses the consumer, and the producers are many other computers on the network sending automated commands via TCP.

[joshua.l.guthrie2.civ]

---

@drjdpowell wrote:

Parallel dequeuing is called the "Worker Pool" pattern, and can indeed be done with LabVIEW Queues (though not User Events).  You can even do it if the order matters, but that is extra work to reassemble the order.

---

Worker pool, I was trying to think of that term.  Thanks!

From the previous (old) posts in the thread, it kinda read like never do this in LabVIEW.  Seemed off.  Wanted to make sure there wasn't a specific gotcha in the bowels of LabVIEW's implementation of ques that I wasn't getting.

[drjdpowell]

---

@joshua.l.guthrie2.civ wrote:
Wanted to make sure there wasn't a specific gotcha in the bowels of LabVIEW's implementation of ques that I wasn't getting.

---

There are gotchas if one tries to use User Events for this, but no gotchas with Queues.  It's one of the expected use cases for Queues and I've done this multiple times.