Queues - Differences between LV 5 and LV6

Question

The implementation of queues has changed from LabVIEW 5 to LabVIEW 6.
The old queue VIs still exist for compatibility. Some of the differences
are quite obvious, but there's one difference I don't understand:
The (old) 'Create Queue' VI now is build around the new 'Obtain Queue'
VI. It stores all created named nueues in an array and searches this
array before calling 'Obtain Queue'. In a textbox it says that this is
necessary due to a different behaviour of the new named queues. I don't
see/understand this difference. To make the question clearer:
Were is the difference between between old and new queues when creating
or abtaining a named queue (that already exists)?
TIA,
Thomas
Thomas Ludwig
Institute of Mineralogy
Un
iversity of Heidelberg, Germany

Answer 1

Hi,
Here is some great information on the new queues thanks to Stephen Mercer here at NI.
Queues underwent an overhaul between LabVIEW 6i and LabVIEW 6.1 (not before that). The most obvious change is the conversion from VIs to primitive functions.
The refnum wires themselves are different colors -- they still have "refnum green" on the outside of the wire, but the inside shows the type of data they carry.
LV6.1 exhibits true reference counting. In LV6i, each time you executed "Create Queue" with the same name, you received the same refnum value (assuming you hadn't somewhere called "Destroy Queue"). So you had a single reference running around on all your diagrams.This caused problems for some applications since they had one set of VIs creating the queues and another set using them; the two sets were operationally independent and there was never an easy way to know when everyone was done using the queues and it was safe to destroy them. In LV6.1, the queues and notifiers are properly reference counted. This has zero impact on unnamed queues. But for named queues, each time you "Obtain Queue" for the same name, you get a different refnum value. IT STILL POINTS TO THE SAME QUEUE. But now many different VIs can acquire refnums to the same queue and release each of their refnums when they are done with them. When the last refnum is released, we (LabVIEW) know it is time to actually destroy the queue. That's why the names "create" and "destroy" were changed. The way I've explained it to others: think of the queue as a tire. The refnum is a rope attaching the tire to a low hanging tree branch. Each time an "Obtain Queue" is called for the same name, a new rope is added tying the tire to the branch. When a "Release Queue" is called, one of the ropes is removed. When the last rope gets removed, the tire falls to the ground -- the queue is removed from memory and its data is thrown away. The special terminal on "Release Queue" called "release all?" can be wired with TRUE to invalidate all refnums for this queue and immediately cause its destruction.
What does this mean to a user? It means that you want to include a "Release Queue" for every "Obtain Queue" you use or risk continually allocating 4 byte refnums that aren't cleaned up until the end of your VI's execution. Most programs don't notice the continuous allocation, but those that are designed to run for long periods of time (days) have had a bit of trouble with this concept. It also means you are better off actually running the refnum wire to the various points of your diagram that need it rather than -- as was frequently done in LV6i -- taking the shortcut of doing another "Create Queue" in each physical location where you need that refnum. All refnums obtained by a given VI heirarchy will be cleaned up automatically when that VI heirarchy stops execution, but if you want them cleaned up sooner, use "Release Queue".
The 6.1 queues have a new capability not existing in 6i. The "Preview Queue Element" primitive allows you to inspect what the front element of the queue is without actually taking it out of the queue. This is useful for doing look-ahead work.
There are new example programs that ship with 6.1 to help you understand the queue behaviors.
Bryan Dickey
Applications Engineer
National Instruments
http://www.ni.com/suppport