LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Producer/consumer pattern, why queue?

With queues the consumer will execute all the events queued up on First-In-First-out bases. Events/triggers still in the queue waits until all the loops are executed. Usually you will have loop for each event/trigger and you use case structure in the consumer loop for each event.

 

Message 21 of 28
(989 Views)

I'll consider this is a state machine controlled by Value (signaling), not by an enum. The one element in the queue will decide what's next; two elements there will provide a choice.

I will have a automated test button, if it's true, it will go by sequence; or it will go by clicking buttons. If it's true, all the buttons will be locked, so user will not be able to click them.

0 Kudos
Message 22 of 28
(987 Views)

As mentioned it would help if you described your desired application a bit better. Forget about buttons and value signaling. State in basic requirements what you want done. Don't include the how part.

 

If I want an event that mimics the same thing as value signaling I create a corresponding user event for that action. The consumer (or any other task that needs to generate this action) will fire the user event, not update a local variable/property node and rely on value signaling. The event structure that services the button can also service the user event. I also use user events when I need two way communications between the producer (while loop with an event structure) and the consumer. The producer uses a queue to send information to the consumer and the consumer uses users events when it needs to send something to the producer.

 

A few other benefits of queues that have not been mentioned is that under the hood queues ensure that one and only one thing modifies the queue. This provides protection against race conditions. There is automatic semaphore locking on accessing the queue for modification (enqueue/dequeue/flush). Also, if a consumer is using a queue to runs it's tasks it will be idle if nothing is queued. If you use a local variable you need to create a polling loop which means you are using CPU cycles even when there is nothing to do.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 23 of 28
(976 Views)

Hi Mark,

 

Thank you for the advice.

 

This program is about to test a device with network capability. I'm using Packet Sniffer Example I found online to sniff packets. I'll call this one sniffer loop. The other loop is the event structure which will send commands, I'll call it main loop. The main loop will send a command to the device, at the same time send a cluster to the sniffer loop. The cluster will include a string and a enum. String will tell the sniffer loop what to look for and enum will control a case structure to do some specific processing. The sniffer loop, after grapping data or timed out, will send back another cluster back to main loop; the cluster will include a string and a boolean. The string will tell the main loop what it has got and boolean will just tell whether the search is successful.

 

I don't know whether I have made myself clear. I'm in the planning stage of the process; I just want it to be well planned.

0 Kudos
Message 24 of 28
(964 Views)

Your requirements sound much better suited to a state machine than a producer/consumer architecture. Your description seems to indicate a synchronization between the two loops. If this is the case one idle while the other works and vice versa. If one loop is always waiting for something from the other this really is much more of a state machine than two independent tasks like a producer/consumer.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 25 of 28
(958 Views)

The main loop is a state machine. It will wait until information from sniffer loop's back. Then it will send another command and wait for some other information.

 

Both two loops will produce data/command for another loop. I'm considering to have two queues to handle the traffic in both directions.

0 Kudos
Message 26 of 28
(950 Views)

Does your upper state machine run others things while the consumer (sniffer) loop is doing anything? Does the upper loop have to wait until the sniffer loop completes its task before continuing? If not than the sniffer loop is basically just another state in the state machine. Based on your description I don't think you need a producer/consumer archtecture. A single sate machine shold suffice. Unless both tasks are doing somethingat the same time you don't need to complicate your application by using an inappropriate design pattern for the given task at hand. While the producer/consumer architecture is extremely useful and powerful, it is not the idle design pattern for every problem.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 27 of 28
(943 Views)

The main loop, after sending command, will wait for information from another loop. Sniffer loop will run all the time. There are times they both run and sniffer is not one of the cases.

 

I think I'm getting clear now that I will need two loops and two queues to handle the task.

0 Kudos
Message 28 of 28
(934 Views)