Producer/consumer pattern, why queue?

[SteveChandler]

You can indeed use another queue. A common approach is to use a user evemt to send data from the consumer to the producer since you already have the event structure.

[guangdew1]

Hi Steve,

Could you explain further regarding using user event to send data, is it just an another queue to produce data to be consumed by the other loop? I am using an event structure to deal with user event, but basically these events are all going to be triggered by Value (signaling).

[nathand]

---

guangdew1 wrote:

Could you explain further regarding using user event to send data, is it just an another queue to produce data to be consumed by the other loop? I am using an event structure to deal with user event, but basically these events are all going to be triggered by Value (signaling).

---

This is a very good indication that there is a problem with your intended architecture.  You should not be triggering a series of events using Value (signaling).  That's part of the reason for using producer-consumer - it lets you queue a series of commands, without relying on front panel controls.

[guangdew1]

What's in my mind is that I'm going to have all the events waiting in line, then send them to the queue one by one after it gets the status signal from the other loop.

[nathand]

---

@guangdew1 wrote:

What's in my mind is that I'm going to have all the events waiting in line, then send them to the queue one by one after it gets the status signal from the other loop.

---

I don't know exactly what you mean by "waiting in line" but generally the way producer-consumer works is that you have an event structure in your producer loop that does very little except queue commands in response to user interaction.  So, if the user clicks a Start button, the producer (event structure) queues a Start command.  The consumer loop does the real work. 

The producer loop may do a few other small tasks - for example, if a Stop button is pressed, it might flush the queue, then enqueue a Stop command.  Also, the consumer loop might generate user events, which would be handled by the producer loop.  For example, if the consumer acquires data, it might send a Data user event to the producer event structure to update a graph.  These tasks should be handled quickly, so that the interface remains responsive.

[guangdew1]

What I mean is that I'll have these buttons, which either show on the front panel or not, they are going to be triggered one by one by Value (signaling), or they can be triggered by clicking the buttons individually by user. For automated process, they are going to be triggered one by one after started. Data from another loop will decide whether or where it will go.

[nathand]

---

@guangdew1 wrote:

What I mean is that I'll have these buttons, which either show on the front panel or not, they are going to be triggered one by one by Value (signaling), or they can be triggered by clicking the buttons individually by user. For automated process, they are going to be triggered one by one after started. Data from another loop will decide whether or where it will go.

---

This is where the problem lies.  Instead of triggering Value (signaling) events, you should be building up the queue for the consumer loop.  This gives you much more control over the queue order - you can flush it if necessary, and add elements at either end, which you cannot do with the event queue.  Your approach sounds like you never want more than one item in the consumer queue at a time, which is backward - one reason for using a queue is so that you can have multiple elements in it.

[guangdew1]

It's true that I wanted to have one element in queue at a time, some times maybe two. But I don't see the benefit of enqueuing everything in the beginning of process. Could you explain the benefit of it?

[nathand]

---

@guangdew1 wrote:

It's true that I wanted to have one element in queue at a time, some times maybe two. But I don't see the benefit of enqueuing everything in the beginning of process. Could you explain the benefit of it?

---

Again, this gives you more control over the sequencing; it can prevent an event from being queued in an unexpected order if the user clicks a button while the automated sequence is running (because all the events will already be in the queue in the right order); it lets the consumer loop move on to the next task as soon as the previous one completes; and it's better programming practice.

How do you intend to space out the Value (signaling) events?  What do you see as the benefit to minimizing the number of elements in the queue?  Why would you couple your sequencing to your user interface unnecessarily when you're running an automated sequence?

[K.Waris]

It could be easier to suggest the better solution if you describe what data is coming from the producer loop. If it is the data acquired from an RT/FPGA target then you might as well think using single process shared variables with RT FIFO enabled to communicate from producer to consumer. They are very good and will save you wiring on the block diagrams as well. You create shared variables in project explorer by right clicking relevant target.

Even if it is a DAQ/PXI device you could still get away without communicating back with data acquisition loop. I dont see why you need to communicate with producer loop from consumer loop. Do only acquisition in producer and send data to consumer using queues/FIFOs/Shared variables. Do all calculations in consumer loop and create another loop call it display loop to update front panel.

Going back to original concern of yours about the difference between local variable and queues, I suggest you should see examples shipped with labview development suite- just type queues/local variables in search box. Hope it helps!