Dequeue data to multiple while loops

[William1225]

I feel like the 'Notify' feature might be what you need.
What Is a Notifier in LabVIEW? - NI

[pincpanter]

---

@William1225  ha scritto:

I feel like the 'Notify' feature might be what you need.
What Is a Notifier in LabVIEW? - NI

---

Notifiers are intrinsecally lossy. They return the most recent data. To use notifiers, you must start waiting before the producer starts getting data and be sure that the processing time is always shorter than the data acquisition period. This is often impossible.

[drjdpowell]

I would suggest one Queue per consumer, with the producer keeping the Queue references as an array.

[JÞB]

I'm going to bring up yet another method.

Use a Channel Wire.  In fact, the Stream Channel built in function "Replicate" was designed exactly for these case where multiple consumers must receive the exact same Data in the exact same order without loss.  With that consideration, I would certainly move to the newer synchronization paradigm myself (but ensure I liberally peppered the code with comments and even links to the LabVIEW Help and Examples for the next developer)

---

[Kevin_Price]

Multiple queues can work just fine.  Thanks to JÞB, I now know that a Stream Channel can be replicated to accomplish the same goal in a mostly similar way.  (Where I've been working we have a pretty big IP investment in a modified QMH reuse framework, so I still haven't explored Stream Channels very much.)

But here's a unique feature of a solution based on user-defined events:  the producer doesn't need to know how many consumers there will be.  You can add consumers without modifying any of the code in the producer.  So for example, your producer could be part of a locked-down executable that can dynamically launch consumers as plugin modules.  So long after the executable with all the core functionality has been built, you can add nice little plugins for visualization, live processing, alternate file formats, etc.

-Kevin P

[JÞB]

---

@Kevin_Price wrote:

Multiple queues can work just fine.  Thanks to JÞB, I now know that a Stream Channel can be replicated to accomplish the same goal in a mostly similar way.  (Where I've been working we have a pretty big IP investment in a modified QMH reuse framework, so I still haven't explored Stream Channels very much.)

But here's a unique feature of a solution based on user-defined events:  the producer doesn't need to know how many consumers there will be.  You can add consumers without modifying any of the code in the producer.  So for example, your producer could be part of a locked-down executable that can dynamically launch consumers as plugin modules.  So long after the executable with all the core functionality has been built, you can add nice little plugins for visualization, live processing, alternate file formats, etc.

-Kevin P

---

I would note that there is one small difference between using either replicated Streams or multiple queues and Events.

Event Structures are normally many to 1 rather than 1 to many.  They can become many to many.   What this means in practice is that there is NO GUARANTEE that all consumers of your Event Producer are operating on the same data at any given time.  

Take the case where Event Consumer A is also registered for another Event that Event Consumer B is not registered for.   Event loop A may get delayed with that other Event and then lag behind Event loop B in processing the Producer data.  This could cause some "issues that need tissues" to debug.

A Replicated Stream Channel approach has a firm 1 to Many communication path guaranteeing that no other interrupting messages can be stuck in the Stream 

Multiple Queues are inherently weak for 1 to many uses.    The next guy could; Flush, Enqueue, Enqueue Opposite End, Destroy or do other bad things to any queue away from the single Producer and Consumer you expected the next guy to respect.  Those "Bad things tm" are protected against by using Stream Channels

Additionally,  if the process time of each Consumer is vastly different, Channels also offer ACK options to let the Producer know when each Consumer endpoint got the message. 

So, for myself,  this is case where I would have to have written a lot of debug and safety code prior to Channel Wires existence. 

[JÞB]

---

@JÞB wrote:

---

@Kevin_Price wrote:

...here's a unique feature of a solution based on user-defined events:  the producer doesn't need to know how many consumers there will be.  You can add consumers without modifying any of the code in the producer. 

-Kevin P

---

Event Structures are normally many to 1 

So, for myself,  this is case where I would have to have written a lot of debug and safety code prior to Channel Wires existence. 

---

Kevin did point out that there ARE cases where the number of Consumers is not knowable.  And, I only teased how I handle that.

It's fairly simple.  

• Develop a "ThisSuperEvent Consumer Loop.vi" TEMPLATE. 
• Document the producer loop vi with "All consumer's of this Event must use Template ThisSuperEvent Consumer Loop.vi" located at <path> from New>>VI from Template>>MyTemplates...
• Document the "Rules" of the Consumer loop development (i.e. may NOT add event cases, may NOT Destroy User Event, etc...)
• Wait for the first developer to ignore the comments on the original code 
• Select an appropriately large stick
• Publicly beat the offending developer with selected large stick.  <I find this discourages other developers from making the same poor choice.> 😈

[mcduff]

---

@JÞB wrote:

I would note that there is one small difference between using either replicated Streams or multiple queues and Events become many to many.   What this means in practice is that there is NO GUARANTEE that all consumers of your Event Producer are operating on the same data at any given time.  

Take the case where Event Consumer A is also registered for another Event that Event Consumer B is not registered for.   Event loop A may get delayed with that other Event and then lag behind Event loop B in processing the Producer data.  This could cause some "issues that need tissues" to debug.

A Replicated Stream Channel approach has a firm 1 to Many communication path guaranteeing that no other interrupting messages can be stuck in the Stream 

Multiple Queues are inherently weak for 1 to many uses.    The next guy could; Flush, Enqueue, Enqueue Opposite End, Destroy or do other bad things to any queue away from the single Producer and Consumer you expected the next guy to respect.  Those "Bad things tm" are protected against by using Stream Channels

---

Most of the things you listed are exactly why I use Events, :). They are more work, but highly flexible. The same "mailbox" can receive messages from multiple senders, also handle front panel events, and even handle DAQmx events. A consumer can receive a "Stop" message from anywhere in the program, not just the producer. Channels and queues are extremely useful but still not as flexible in my opinion.

[JÞB]

---

@mcduff wrote:

---

Most of the things you listed <by JÞB> are exactly why I use Events, :). They are more work, but highly flexible. The same "mailbox" can receive messages from multiple senders, also handle front panel events, and even handle DAQmx events. A consumer can receive a "Stop" message from anywhere in the program, not just the producer. Channels and queues are extremely useful but still not as flexible in my opinion.

---

DANGER DO NOT DO!

I would say it is "permissible" to send a request to a producer to "Send Stop Message to all Consumers,"( or any message) with or without priority, from other areas of a program.  BUT, would seriously question (at code review) any reason to inject secondary command paths into a Producer Consumer paradigm. 

That does not include the scope of intended Many to 1 pattern utilities.  Error logs, User Messages,  etc... those are not the same thing the OP topic is considering. 

[mcduff]

---

@JÞB wrote: DANGER DO NOT DO!

I would say it is "permissible" to send a request to a producer to "Send Stop Message to all Consumers,"( or any message) with or without priority, from other areas of a program.  BUT, would seriously question (at code review) any reason to inject secondary command paths into a Producer Consumer paradigm. 

---

This is a valid point; however, most of the time I am not in a strict Producer-Consumer paradigm. For example, I have a DAQ loop that "produces data" for a "Data Loop." The data loop produces data for the user to visualize. Sometimes the user wants to filter the data, FFT the data, see a spectrogram of the data, etc. So the user sends a message or secondary command to the data loop to tell it what to produce, even though it is also a consumer of the DAQ data. 

---

@JÞB wrote:

I would say it is "permissible" to send a request to a producer to "Send Stop Message to all Consumers,"( or any message) with or without priority, from other areas of a program.  

---

Why have a "middle man"? Not sure I see any significant advantages of have a two layered message approach.