Is there any reason to use the Producer-Consumer Model if I'm not collecting data very fast?

[optoelectro]

Hi, here's what I want to do:

I want to take measurements from my device for a given length of time, and then average all those values, and then save that average to file. Then, I want to delay for a different length of time, and then repeat the process.

Previously, for a different project, I used the Producer-Consumer model to continuously collect data (in the Producer loop) and process and save it to file (in the Consumer loop), but that was because I wanted pretty high time resolution in my my data collection, and it would've slowed it down if it had to save to file between each measurement.

However, for my current project, the time resolution isn't as important; I basically just need to collect a bunch of data points during the "collection" phase I mentioned above.

So, is there any reason to use the P-C model? Or would it be simpler and smarter to just use a loop within another loop, with a delay?

I guess my main worry is that adding to the array in the "collection phase" will be too slow, but it should be a lot faster than saving to disk right?

thank you!

[James.M]

It's really common to have a consumer loop do all the processing saving to disc, just so you don't lag your UI. A simple Queue'd Message Handler could do this for you and you could still do your slow data acquisition in the interface loop. It doesn't take long to actually acquire the data points, it just takes time to process and save.

If it's really slow acquisiton and you don't care about a little lag, you could have it all in one loop honestly. Architectures are all about building something that will get what you need done, without overdoing it. Take a look at bother the Simple State Machine architecture and Queue'd Message Handler architecture, both ship as templates with LabVIEW 2012 and newer.

[Rodéric]

Using a design pattern will improve your code neatness. As stated before, it will improve your user experience by reducing the UI lag.

[crossrulz]

In any real application, I always have the logging done in a parallel loop.  Even if you collection is slow, it helps the organization of your code to have it seperate from your acquisition.

---

optoelectro wrote:

So, is there any reason to use the P-C model? Or would it be simpler and smarter to just use a loop within another loop, with a delay?

---

A loop within a loop is generally a bad idea.  If you are doing that, it sounds like you need a state machine.

[Bob_Schor]

Speed is (like Beauty) in the Eye of the Beholder.  I often sample at 1KHz.  If I collect 1000 samples at a time from 16 channels, then every second I am generating 16,000 samples.  That takes 1 second.  To write 16,000 samples (assuming I've already opened the file) should take me far less time ...

It seems to me that if you already have code that works and uses Producer/Consumer, there might be nothing wrong with simply "reusing" it for a much slower system.  One less code pattern to debug, and should the need arise to up the sampling rate, you are already prepared.  Plus there's something to be said for utilizing LabVIEW's parallel-processing abilities (who knows what time-intensive computation you'll want to add next week?).

Bob (If it Ain't Broke, Don't Fix It) Schor

[Hooovahh]

Some comments touched on this, but another reason you might want to considere a producer consumer model, is for increased modularlity.

If you can have a messaging structure, where sending a message on a queue has a loop perform an action, then that loop can be unit tested without needing the whole application.  Potentially a developer can go off and make that code module (or actor maybe) and deliver that to the rest of the team.  All they need is to define the public events that it is responsible for, with the inputs and outputs.

This can make for more reusable code because I could potentially take a logging module (or actor maybe) and copy it from one project to another keeping the functionality I added.  Maybe I added a way to make a new log file at midnight, or split the file after reaching some size, or periodically closing defragging and opening the file if it is TDMS.  How about wrapping in pass fail checking.  Now I have a module that has lots of cool functions, and all that is needed is the interface into it using a message like a queue.

Another reason for producer consumer is a different type of code reuse.  I can write code that performs some action once, and I can invoke that code from multiple places in the software by simply telling that module to execute that feature.  Lets say my UI has a button for performing a shutdown.  If that button send a messge to a module that handles that shutdown, I can call that same message at the end of a test.  Now the actual code performing the shutdown is in one place.  And the code the UI invokes is the same that the sequence code calls, which can reduce the likelyhood of bugs with different shutdown methods that you assume are the same, until you have to update one and forget to update the others.

[optoelectro]

Hi everyone, thanks for the advice. I'll keep it in mind as I make my programs. Thanks!

[mikeporter]

The way I like to think about it (and which covers most of the examples given) is that the producer-consumer pattern is a special case of a more general concept of "parallel is good". Seldom will a single process consume all the bandwidth available. In fact this obvious truth is the foundation for all modern operating systems.

Anytime you can spawn off a process to do something in parallel -- that's a good thing.

Add into that the advantages it brings in terms of modularity and reusability, and you have a real winner.

Mike...