Semaphore Refnums & Queue Refnums - Why weren't they included in the Controls Palette???

[tarheel_hax0r]

I would like to be able to pass data between windows. [We have dual monitor setups, and typically I like for all the buttons to be in a window on the first monitor, and all the waveform graphs & charts to be in a window on the second monitor.]

One obvious way to pass data between two windows is to have a third, hidden window that contains nothing but global variables that can be accessed by the two visible windows - I'm very familiar with that approach.

However, I thought it would be really nice to use either semaphores or queues for the inter-window communications, but when I searched in the Controls Palette, I couldn't find any pre-packaged refnums for those phenomena.


However, I did find refnums in some rather quirky places.

After perusing the following examples

C:\Program Files\National Instruments\LabVIEW 7.0\examples\general\semaphore.llb
ftp://ftp.ni.com/contrib/epd/B45EACE3E05056A4E034080020E74861/Queue_Example.zip

I came to realize that there are "Strict Type Def" refnums for Semaphores and Queues in these libraries:

C:\Program Files\National Instruments\LabVIEW 7.0\vi.lib\Utility\queue.llb
C:\Program Files\National Instruments\LabVIEW 7.0\vi.lib\Utility\semaphor.llb

But there doesn't seem to be much in the way of documentation for these refnums.

So now I'm wondering why these refnums weren't included in the Controls Palette, and of course I'm also wondering whether there is any good documentation on the proper [safe] use of these refnums.

Thanks!

[tarheel_hax0r]

 
I've attached a [broken] VI that shows some of the difference between the documented approach to Queues [which involves naming queues with strings], and the undocumented approach to Queues [which involves passing refnums].

The documented approach:

Obtain Queue
Enqueue Element
Dequeue Element
Get Queue Status
Flush Queue
Release Queue

The undocumented approach [no Help files]:

Create Queue.vi
Insert Queue Element.vi
Remove Queue Element.vi
Get Queue Status.vi
Flush Queue.vi
Destroy Queue.vi

I guess I'm just a little worried that because the refnum approach is undocumented [no Help files], maybe it's been deprecated, or maybe it's an unstable beta release, or maybe it's stable, but there are some non-intuitive "gotchas" tha
t need documentation...

Anyway, thanks again!

[EdDickens]

I'd recommend using the Named Queues that are found on the current palette. The 'Queues with Refnums' are the older style of queue VIs that are depreciated. They can only accept a string as an element, so anything you want to pass into the queue must first be cast to a string, then cast back to its original datatype. The new style is polymorphic and can accept any data type.

To get a reference to the new style of queues in different VIs, you just need to use the 'Obtain Queue' vi and use the same "Name". This will create a link to that particular queue. You just need to remember to use the "Release Queue" function once for each time you use the "Obtain Queue" function as it releases it for that "Obtain" only. There is an input on the Release Queue cal
led "Force Destroy?". If you put a 'True' on this input, it will destroy all references to the queue and you will no longer be able to use it.

Ed

[tarheel_hax0r]

Thanks - that explains a lot.

The 'Queues with Refnums' are the older style of queue VIs that are depreciated.

I had assumed that since "Identification by Refnums" [pointers] seemed more sophisticated than "Identification by Names" [strings], then the Refnum approach would be the newer, more sophisticated way of doing things.

They can only accept a string as an element, so anything you want to pass into the queue must first be cast to a string, then cast back to its original datatype.

Just last night, I was playing around with the Refnum approach, specifically

C:\Program Files\National Instruments\LabVIEW 7.0\vi.lib\Utility\queue.llb\Create Queue.vi

It turns out that this "Create Queue.vi" is just a wrapper for the new
"Obtain Queue" function, and within that wrapper, they submit an empty string to "Obtain Queue", so I just changed that to an empty version of the homebrew data type that I wanted to use, and saved the VI with a new name [essentially just "Create My Homebrew Datatype Queue.vi"]

But if "Identification by Names" [strings] is the wave of the future, then I guess I'll abandon all that Refnum stuff and get with the program.

PS: It is really strange, though, to access something as sophisticated as a queue [between threads in a virtual machine] by nothing more formal than a name [i.e. a string]. It also raises the possiblity of identifier-collision [since it's entirely possible that two programmers could both choose to name their queues something like "MyDataQueue"], but I guess there are some pretty obvious safeguards you could take to minimize the chances of that happening.

[EdDickens]

The new queue functions generate a refnum also, but it's a specific type of refnum called a "Queue Refnum". It�s essentially a refnum packaged with an identifier that specifies the datatype of that queue. Notice the refnum wire changes colors and/or patterns with different datatypes.

With the new queues, you can also pass arrays and clusters directly into the queues instead of just single element datatypes.

Identifier-collision could be a problem, so it�s definitely something you�ll have to watch out for.

Ed