Named queue vs feedback node global queue

[infinitenothing]

Is there a reason to use named queues? If I ever want to grab a reference to a queue without a wire, I just call a non-rentrant VI that looks like the attached code

The advantages are:

• One place to setup queue size
• No typos
• Can output multiple refs

What are the advantages of a named queue?

• Dynamic queue selection
• Anything else?

Edited January 30, 2015 by infinitenothing

[crossrulz]

Personally, I keep an Action Engine for each communications queue I need.  The AE is used to initialize the queue, close the queue, and send the messages.  Besides, only one place should be doing the dequeue.  Plus then nobody else cares how the message is sent; they just call that AE.  You can look here to see how mine are typically set up.

[ned]

One place I've used named queues is the rare situation where you want two top-level VIs to access the same queue. For example, I once had an application that relied heavily on queues, and I wanted to do some debugging on the items that were getting put into the queue without making major changes to the main code. I simply named the queue in the main VI, then created a separate VI that obtained a reference to that same queue and ran "Get Queue Status" repeatedly so I could constantly see the contents of the queue.

[ShaunR]

Don't underestimate dynamic queue selection but to add one more  - "re-use".

 

If all your global non-rentrant VIs are the same type, (a variant, for instance) all your globals' diagrams will look identical (it's only the refnum you are really after). Then you will notice that all those global diagrams are identical AND all you are doing is enqueuing and dequeuing these.  That should be smashing your brain with the Hammer of Re-use Reminding but you will find it oddly difficult to push the Get Refnum, enqueues and dequeues down into a reusable, generic subVI.

 

It's the same issue with events.Encapsulation doesn't enable resuse and no matter how hard you try to encapsulate to create a generic form (a requirement for this type of re-use), you still end up with a specific implementation. However, encapsulation and genericism can be achieved with named queues due to the "Obtain Queue" and is the main advantage of queues over events.

Edited January 31, 2015 by ShaunR

[pawhan11]

In my recent projects I use one FGV that stores all my Queues and Events references in Cluster. When I need to get some element I just unbundle it from cluster. 

When I use only one data communication mechanism I could store it as a variant attribute in FGV and get it by name to avoid placing unbundle by name.

 

When adding elements I created polymorphic vi to handle events, queues and UE. It makes my programming faster

 

I was trying to push it more to avoid wasting time on unbundling these queues and transforming variants to data but so far I was unable to find something better...

[drjdpowell]

Note that a named queue can have multiple independent references to the same queue, while the non-reentrant subVI contains only a single reference.  

[ShaunR]

In my recent projects I use one FGV that stores all my Queues and Events references in Cluster. When I need to get some element I just unbundle it from cluster. 

When I use only one data communication mechanism I could store it as a variant attribute in FGV and get it by name to avoid placing unbundle by name.

 

When adding elements I created polymorphic vi to handle events, queues and UE. It makes my programming faster

 

I was trying to push it more to avoid wasting time on unbundling these queues and transforming variants to data but so far I was unable to find something better...

 

Indeed. However, by putting it into a sub VI it has only made it more application specific (what are the chances your global, global VI of refs has exactly the right datatypes and clusters from project to project?).

 

For raw data on a particular project it doesn't really matter. You'll create all the queues and then discard them and create new ones from project to project.The advantage being "look Ma, no wires" rather than generic re-use. Once you start looking at messaging for control, however, you will be looking for a generic method and that is when named queues become far more attractive.

 

This is a little VI you will find in almost all of my projects. I use to for command queues for services. It is not application specific since it does not have any application specific data types and look Ma, no wires.

 

SR Queue.zip

Edited January 31, 2015 by ShaunR

[pawhan11]

Thanks for that example. I will think about making new approach to how I do things in upcoming week. 

 

When comes to datatypes I always make cluster that has string and variant inside as a data type. That makes it generic but adds casting from variant when reading and that can be annoying to do but when I use the same queue to transfer different data types that is only one option I can think of. So adapting that to new project is only about making/removing these queues.

 

I have found there is something like Xnodes, so maybe it is possible to join read from queue and UE vis with casting variant to specific datatype but so far I don't know how to do that.

Edited August 20, 2015 by pawhan11