Using Lossy Queue vs. Get Notifier Status vs. Wait on Notification to Provide Latest Value in Consumer Loops

[ChuckVersusTheVI]

I have a producer loop on a RT app acquiring signals as an array of waveforms. I have N consumer loops that need to asynchronously read the latest value of the array of waveforms.

To convey the signals to the N number of consumer loops, which of the following would be better in terms of (a) memory efficiency and (b) execution speed?:

• Limited Sized Queue -  Separate queues for each consumer, producer uses lossy enqueue, and consumers make sure to dequeue fast enough to keep the queue below the allocated size.
• Notifier - Single Notifier for all consumers, each consumer uses Get Notifier Status.
• Notifier - Single Notifier for all consumers, each consumer uses Wait on Notification with a timeout and remembers it's own copy of the previous value.

Each consumer loop should not affect the execution speed of the others, so calls to get the latest data should not be done synchronously as in the case of a single FGV being used to hold the data. 

Additionally, is there a better solution than what's listed above?

For reference, the RT app would be run on a cRIO 9045 using LabVIEW 2024 Q1.

[Kyle97330 · Accepted solution]

Just to clarify:

The asynchronous consumer loops only need the most recent value?  They don't need any history or the ability to accurately check the change from one value to the next?

If so, I would say that queues are not great.  Each of your consumers would have to send a message to the producer letting it know to start enqueueing to one additional queue each measurement, and another when they close to turn off the queue.  Each additional queue also takes up its own memory space, and CPU time to enqueue to each of N queue references.  Queues are best thought of as "Many to one" or "one to one" and this would be using them in a "one to many" configuration, which isn't their intended or optimal use.

Notifiers are a "one to many" design at their core, so are much more appropriate for this. As for the options, between the two options I think it mainly matters how much the data is a core part of their design vs. an incidental data point.  If it's a core part of their functionality, I would think that "Wait on notification" is the most appropriate, because then as soon as a new notification comes in it wastes no time in doing whatever it needs to do after a data update, and when it waits it's not using CPU time redoing operations on old data for no benefit.  If it's more incidental, then running a loop on an independent timer and just getting the most recent status whenever the value is needed makes more sense.

[ZYOng · Accepted solution]

Share only the latest data using RT-FIFO. It is the underlying architecture of VeriStand.

VeriStand Engine

Real-Time FIFO Frequently Asked Questions

[ChuckVersusTheVI]

Correct, they only need the most recent value, they don't need any history, and they don't care if the value has changed, just as long as it is the most recent. 

When multiple consumers try to access a new notification at the same time, will each call to "Wait on notification" execute synchronously like calls to an FGV? Or do they actually asynchronously access the same data?

In other words, how does the Notifier manage the calls to the same data? Does it send a copy of the data to each of the "Wait on notification" instances? Or Is it just one copy of the data that each call has access to, and is that really done asynchronously?

Would the RT-FIFO be considered a better "one to many" solution than a Notifier for this scenario? "Better" in terms of memory usage and execution speed.

[Kyle97330]

I have not used RT at all, RT-FIFO included, but it appears to basically be a modified queue to work much faster under RT conditions in exchange for several restrictions on its use.

If you're having no problems meeting your RT scheduling or whatever then I still think a Notifier is the way to go.

As far as the memory allocation, I did a test and on standard, non-RT LabVIEW it appears that a Notifier has a 2-element history, so the total required memory for just sending notifications is 2x the size of the data that you send.  As for the different receivers of the data, I didn't try that but it's a fair bet that at the very least the first receiver will need its own memory space (since the original memory space could get cleared for the next notification at any moment).  After that, LabVIEW has some optimizations in it to not duplicate memory allocations when it doesn't need to (such as when one large array gets branched into several different destination nodes in the same VI) but I have no idea if Notifiers use those optimizations when read by different VIs.  I wouldn't count on it.

What's the size of the data you're looking at here?  And how strict are your real-time requirements?

[ChuckVersusTheVI]

I don't have a good measure on what is truly real time, but for purpose of this question each consumer loop would run no slower than 100 ms.

For data size, the array of the waveforms would max out below 200 elements, where each waveform only has 1 element in its 'Y' array by the time the data is sent to the consumers.

So to summarize:

• Use a Notifier and 'Wait on notification' in each consumer loop instead of a fixed size lossy queue or 'Get Notifier Status'. Each consumer loop would keep track of the latest value it received in the event of a timeout.
• Use a RT-FIFO if I need faster performance than what the Notifier method produces, and if I can afford the restrictions that come with RT-FIFOs.

[crossrulz]

---

@ChuckVersusTheVI wrote:

I don't have a good measure on what is truly real time, but for purpose of this question each consumer loop would run no slower than 100 ms.

---

Real Time is not about being fast.  The point of RT is determinism, which mean that a loop will iterate at a set rate with little to no jitter (variance in the loop rates).  If you don't need deterministic loops, then do not worry about the RT-FIFO.