best way to handle this producer-consumer situation

[GregFreeman]

This is, i'm sure a common thing, however, I never really thought about it before. I can't post my VI so a description will have to do. It should go without saying, but I will repeat it's producer-consumer architecture. Let's say you have a signal generator and all the controls for it are in a cluster. A value changes, fires an event in the producer loop and you compare new and old values to determine which button changed. Cool, all good. So then I queue up a read front panel state in my prodcuer loop which is dequeued in my consumer loop. The read front panel state loads all the new values into a cluster which then is fed into a shift register to be accessed from anywhere in my code (see here).

Now my question is, what should my next state be that I queue up? If I have a single "send commands to sig gen" state, in my consumer loop I again have to determine which value changed in order to know which command to send (because the original determination of what changed was in the producer loop). However, if I have an individual state for each command I want to send, my case structure will get very big, very fast.

Final option is have one send command state and just write all data on a single control's value change, whether it's new or not (this seems overkill).

Suggestions please?

[johnsold · Accepted solution]

For situations like this I would not send a "state" to the consumer.  I send a "command."   When the consumer receives a command, it determines whether that command is executed immediately or whether it completes the task in process and then handles the new command.

Along with the command I send a parameter or parameters.  For your signal generator the parameters would probably be something like a cluster of "control ID" and "value."  The control ID would probably be a typedefed enum and the value a DBL.

What ever you decide, think about it, plan it, and document it before you code it.

Lynn

[tbob]

---

@for(imstuck) wrote:

 A value changes, fires an event in the producer loop and you compare new and old values to determine which button changed. ).

---

Instead of doing your compare in the producer loop, why not do the compare in the consumer loop and send the proper command?  Your consumer loop already reads the front panel to form a new cluster.