Queues: better to pass a refum or the name?

[eaolson]

I like using producer/consumer type patterns. For example, one loop watches for user input, then sends a command to a waiting loop to actually process that input. Often, it's necessary for a sub VI to use one of the queues, and I'm just wondering if there is a preferred method of passing the queue to the sub VI. Usually, I pass the queue refum itself (generated by Obtain Queue) as an input to the sub VI. That way, the queue is created only once, in the top-level VI, and released there as well. Any loop in a sub VI waiting on the queue would then quit.

I think I remember reading somewhere that this may not be the most desiriable way for the sub VI to get the queue. Each sub VI could obtain its own copy of the queue if it knows its name, instead. The refnums generated this way are different, I believe, even though they actually point to the same queue.

Is one of these two methods generally preferred over the other?

I'm still using 7.1.1, and there is a bug when obtaining multiple copies of the same queue by name, but I believe that only rears its ugly head when getting many thousands of copies, as in a loop.

This would apply equally well to notifiers, I assume.

[Mike Ashe]

I obtain almost all my queues by name. I also like to be able to keep track of where queues are being used and monitor them, so I often use a couple of wrapper VIs to facilitate housekeeping. If a VI wants a queue, it calls the wrapper, which returns the queue, but also updates tables of queue name and who (which VIs) are using each. It lets me do a simple monitor that shows all the named queues in an application and loading. If you put things in debug and single-step modes and watch the queue list it sometimes helps in debugging a big app that uses a lot of queues.

YMMV

[ned]

You might want to see this post about obtaining queues. It's not that there's a bug in obtaining multiple copies of the same queue by name, it's by design - every time you obtain a queue by name you need a corresponding release queue. You should not do obtain queue in a loop unless you also have a release queue in that loop. Personally I generally pass queue references directly to subVIs in most cases to avoid this problem; the main VI is responsible for both creating the queue and destroying it when it finishes. This approach also allows the main loop to signal termination to any subVIs that may be waiting on the queue, because any queue operation will generate an error once the queue has been destroyed. There are times when having each subVI obtain its own copy of the queue is useful - for example if you want to run and debug just the subVI and it needs a valid queue refnum.

[Aristos Queue]

I obtain almost all my queues by name. I also like to be able to keep track of where queues are being used and monitor them, so I often use a couple of wrapper VIs to facilitate housekeeping. If a VI wants a queue, it calls the wrapper, which returns the queue, but also updates tables of queue name and who (which VIs) are using each. It lets me do a simple monitor that shows all the named queues in an application and loading. If you put things in debug and single-step modes and watch the queue list it sometimes helps in debugging a big app that uses a lot of queues.

YMMV

An unanmed queue cannot be accessed by any other VI. It is the absolute best way to ensure no name collisions occur -- without a name, there cannot be a collision. All of the examples that ship with LV try to avoid naming queues unless there's a driving need (multiple VIs obtaining references to the same queue). That way we don't accidentally have an example that interferes with another example or, worse yet, interferes with other VIs the user is running.

Giving them names does help debugging, as you point out, but I'd wrap that up so that I could turn it off in production code. A named queue is useful for client/server architectures and multiple-dynamic-VI instantiations, where you want lots of VIs to talk to the same queue, but you don't know which VI will be the last to shut down, so you want each VI to have its own reference to the queue.

[eaolson]

An unanmed queue cannot be accessed by any other VI.

By this, do you mean that another VI can not obtain a refnum for an unnamed queue created elsewhere (i.e., with Obtain Queue)? I have no problem creating an unnamed queue in a top level VI and passing that queue's refnum to a subVI for use there.

[Aristos Queue]

By this, do you mean that another VI can not obtain a refnum for an unnamed queue created elsewhere (i.e., with Obtain Queue)? I have no problem creating an unnamed queue in a top level VI and passing that queue's refnum to a subVI for use there.

Sorry for the confusion... yes, I mean that no other VI can obtain a reference. You can pass the reference to a subVI, or send it to another VI through some other communications mechanism, but basically only those VIs to which you publish that refnum can use that refnum.