Reason for Time Delay in Producer Consumer Loop

[David-Baratheon]

In Core 2, the producer consumer while loops have time delays. I was just wondering, is there any reason to include the time delay?

Without a delay, won't the dequeuing get cleared quicker?

[James.M]

You are correct. Can you provide a link to the specific example you're talking about?

[David-Baratheon]

Page 3-7 in the Core 2 book.

I can post a picture of it if I am allowed to (Not sure if there is a copy right issue with publishing part of the book online).

So in your opinion as a LabVIEW architect you would not have any time delay in the producer consumer loop?

[James.M]

My only guess is that maybe they put it in the example to simulate processing time.

Your producer is usually run when the user does something, or is a data acquisition loop. This could be once an hour or once every 100ms as data is acquired.

The data is then sent to the consumer loop and is handled as fast as possible. In my experience, the faster the better so that it can handle the next message/command/data/whatever that comes in. You could have a preference to slow it down as a way to limit the program from working too hard, but that functionality should really be handled at the producer level.

[David-Baratheon]

So in the case of acquiring data and then writing it to file as your producer and consumer loops, both while loops would not have a time delay in.

[James.M]

Yup.

Depends how your data is acquired of course. If you have a DAQmx acquisition set up, you can Start the task and then pull chunks of data at a slower rate using a Wait function to save computer processing.

[Matthew_Kelton]

You could have delays in your consumer loop as well if you wish to process data in chunks.

I do it for file writers quite a bit since I don't care that the file is updated in real time.  I'll do it in other cases where I may be trying to lighten the CPU load and am in a non-ctritical situation.

But, generally, your consumer loop won't have a delay.

[natasftw]

The delay in Core 2 is put there to show you what happens if the two loops operate at different periods.  If I remember correctly, it's a delay you can modify from the front panel to make it either faster or slower than the producer loop.  As you decrease it, you see the elements in the queue drop rapidly.  As you increase it, you see the queue start to build up.  The idea you're meant to take away from this is that you want to create an architecture that allows you to get all of those data points without growing the queue wildly.  It's not a magic fix that makes the processing keep up with the acquisition.  It just makes it easier to do so by running tasks in parallel.