producer consumer loops vs local variables

[DougFerguson]

I am needing to collect data from multiple loops that are running at varied rates. However, I want to collect data at a constant rate. I am using a seperate loop to poll the data from the other loops to get the most recent data.

Something tells me not to use local variables, but to instead use a queue. What are the disadvantages to using local variables and the advantages to using a queue?

[shoneill]

With a queue, you don't loose data.

You can queue up multiple single measurements in the case that the "consumer" loop is bogged down with something else.  As soon as it speeds up again, you'll have ALL data points available.

With a local variable, you only have the LAST value present.

In addition, a QUEUE can be read as many times as there are data points (You have so many elements in the queue......  A local variable doesn't have any specific "new data" possibility except looking for a change.  But then two successive measurements of the same value mess this up...... You can let the consumer loop run at whatever speed you like, it will still get all the values (eventually).  Make sure to set the queue read to a small timeout (maybe 5 ms) so that you don't end up waiting for data that never comes....
Queues are cool.

Shane.

[Kevin_Price]

Queues are especially good for lossless data transfer to a single reader.  If you have a situation where there are multiple readers that only need a recent snapshot, then something like a "functional global" or a Notifier may be more appropriate.  Notifiers offer some nifty options regarding timing and synchronization that aren't readily available with functional globals or local variables.  You program them just like queues, though you'll tend to interpret the meaning of timeouts differently.

-Kevin P.

[DougFerguson]

Thanks for the replys.

Since I am using serial communication for feedback from instruments in my control loops that run at varying rates, I can't get consistent data at a spcified rate. However, the most recent data is sufficient for my purposes. So in that sense local variables will work, but I like the flexibility and control of using a queue.

[Kevin_Price]

Sounds to me like Notifiers could very well work just fine.  The main advantage they offer over a queue for your kind of app is that they allow you to "consume" the same instrument value 2 or more times if that particular instrument updates more slowly than the others.

-Kevin P.

[shoneill]

Kevin,

is reading a notifier value multiple times really an advantage?

If the instruments are slower, shouldn't this be reflected in the values read?  This is precisely why I would choose Queues over notifiers.....

Shane.

[Kevin_Price]

Shane,

Yeah, what you say makes sense too.  I had an assumption in mind which was this:  one main loop that wants to consume these values from a variety of instruments that run in parallel at different speeds.  The one main loop just wants to query the most recent value at its own chosen pace and update the charts & indicators.  Basically, I'm mostly using the Notifiers like LV2 globals, but with a few extra options when I want to use them.

I've been doing this kind of thing lately for some of my displays and it was the first thing that came to mind.  Choosing only to read fresh data would be a better choice if you had multiple independent consumer loops, each consuming from one queue / notifier.  I'm guessing that's more of what you had in mind?

-Kevin P.

[DFGray]

There is another important difference.  Queues and notifiers do not go through the user interface thread.  Local variables do.  As such, queues and notifiers will usually be more efficient than local variables, since they do not cause a possible thread switch.  In addition, it is easy to encapsulate queues and notifiers in subVIs by passing around the reference.  You can do a similar thing by passing around a control reference, but you will take an order of magnitude or more hit in speed over the local variable.

[eaolson]

---

DFGray wrote: There is another important difference.  Queues and notifiers do not go through the user interface thread.  Local variables do. 

---

Locals run in the UI thread? I thought the big performance hit from using Property Nodes is that PNs run in the UI thread, while locals don't. Locals do make a copy of the data, so they're less memory-efficient than a wire.

[DFGray]

All controls/indicators "live" in the user interface thread, so all access to them must go through that thread.  Locals are far more efficient than property nodes because they use the normal update methods while property nodes force a front panel update on each use.  The normal update method caches changes to the front panel and updates periodically.  You can see this in action by writing a simple loop which feeds a changing value to a front panel control.  As you change the access from the control to a local variable to a property node value, the time to execute the program will increase.  In the picture below, this is the left to right sequence.

Message Edited by DFGray on 03-26-2007 08:20 AM