Decided to try Producer/Consumer, need help

[Kai456]

Hey guys,

I've decide to try and implement the "producer/consumer" architecture for my next little project, and I'm a bit lost. Basically, I've managed to map all of my button the way I want them, and I have a good understanding of the architecture. What has me stumped is on the "Take Measurements" tab I want the program to continuously poll for data. The way I see it there are two ways to do this, either put a loop around the contents of that tab, or somehow continuously cue the main consumer loop to open the "Take Measurements" tab. The problem with the first option is that stopping the program becomes a lot more difficult. The problem with the second is I just don't know how to do it 

Any ideas would be greatly appreciated!

[RTSLVU]

Hmmm you seem to have it backwards. I use a Producer Consumer when I have to acquire data at a high speed.

My acquisition (the "take measurements") would be running continuously in the producer loop.

The Consumer loop would display and save the data to a file.

Here's an example:

[Kai456]

But, if I wanted to use event driven synchronization, wouldn't putting the "take measurements" into the producer loop be useless because the loop would have to wait on the event structure?

[proland1121]

Using the producer loop to process user generated events (event structure) is a very common application of the producer/consumer architecture.

However, you can't have a single state within your consumer running forever, as you have stated...

without over-complicating things too much, you have two options.

1) follow RTSLVU's advice and have a stand-alone loop (a third while loop in your case) constantly polling data... Trigger the start of this loop using a notifier, or another method, when you are ready.  Pass the data to your data handling loop (ie. consumer)... you can have multiple queues (1 consumer per queue) any loop may act as a producer for various queues.

2) Have your "take measurements" state run for a set number of values and then Enqueue itself.  This will cause this consumer state to loop while leaving an opportunity for multiple sources to interrupt (user event, interlock, safety equipment failure, etc.). To Stop, have your event handler "Enqueue at Opposite End" and "Abort" state which then flushes the queue... stopping the "take measurements" state from continuing.

Option 2 has small time offsets between each set of collected data.  If you need very high acquisition speed, go with Option 1.

[Kai456]

I managed to solve the problem. Basically, it will measure data, and when the variation is low enough for you, you can press the pause button. I'd like to then implement a save button which will write that data to a file. If I want that save button to also be able to directly save the data without having to pause it, I'd have to create yet another queue. Is there a way to condense all of these queues? 

[wiebe@CARYA]

In the consumer, wire a time out to the queue. Check if the dequeuer timed out. If it does, go to any case you want, for instance the one that updates the measurement.

Note that this will stop updating the measurements when there are queue elements coming in! You'll get event starvation... Several ways around that (PC might not be the best, or perhaps you need several consumers).

[crossrulz · Accepted solution]

1. The is NOT a Producer-Consumer.  A Producer-Consumer is for processing streamed data.  What we are doing here is a Queued Message Handler which performs actions (states) based on the message being sent to it.  Yes, they structurally look similar, but there is a big difference in functionality.

2. You NEVER want to have a loop inside of a state that relies on other ways to stop.  Instead, use that message to set the timeout on your queue and use the timeout situation to read.  Then you just get another message via the same queue to stop reading.

3. The READER of the queue should be in charge of it.  Therefore, close the queue in the Shutdown case of the QMH.  NEVER let a writer close the queue as you will likely destroy the message to shutdown before the reader even sees it.  Yes, I have been burned by this many times.

[Kai456]

Wow, great advice crossrulz. I find it a little hard to wrap my head around timeouts for some reason. The -1 timeout means that the reader will never timeout right? Then, when I hit the measurement button, it tells the reader to timeout after 1s. This causes the reader to read a blank string, which sends the case structure to the blank string case, which is where I'm reading the device. Is that right? Could I use a notifier in this case to perform the same actions? Also, why delete the second error case structure? Thanks. 

[crossrulz]

---

@Kai456 wrote:

The -1 timeout means that the reader will never timeout right? Then, when I hit the measurement button, it tells the reader to timeout after 1s. This causes the reader to read a blank string, which sends the case structure to the blank string case, which is where I'm reading the device. Is that right?

---

That is exactly correct.

---

@Kai456 wrote:

Could I use a notifier in this case to perform the same actions?

---

Instead of a Queue?  I find it best not to.  The reason being a Queue guarantees delivery of a message.  A Notifier will overwrite anything that was not read yet.

---

@Kai456 wrote:

Also, why delete the second error case structure?

---

It did nothing but add noise.  If you have an error, the Dequeue will not do anything.  Though, you could put it back in and force the Shutdown state in the error case, which would close out the queue and device as well as stop the loop.

[Kai456]

Understood. Thank you for your help!