Named Queues in Queeued Message Handlers

Question

I have a question as it pertains to the Producer/Consumer design pattern and using Queued Message Handler.
I know it's a good idea to to name the queues, but it confuses me as to WHY I need to name it. I've never seen an example to where the named queue is used in the BD other than when naming the queue, is there? I've always used a strict type-def Emunerated Control to control my states in the consumer. Isn't this enough? If someone could shed some light, I think it would go a long way to making some of my programs more robust.

Answer 1

In LabVIEW, an application instance (sometimes also referred to as a context) is something which represents a fully enclosed "area". Anything inside this area is unique to it and can't be accessed directly from any other application instance. This includes things like queue references, VI references, loaded VIs in general, etc. Some of these things can be accessed through established APIs (for instance, VI server does allow you to access other instances, but the queue primitives don't). Note that if you load the same VI in two projects and modify it in one of them, the VI in the other will not be updated until you press the green arrows sync button which appears when you do this. Essentially, you get two copies of the same VI in memory.
Applications instances in LV include:
Every target in every open project.
Every executable.
Instances that LV or other toolkits use (like the application builder, which loads the files in a separate instance or the main LV instance, which is used if you don't have a project open). I think the main reason these are used is to prevent collisions.
Note that this is very different from actual namespacing (i.e. libraries like lvlib and lvclass) in that this is something transient. It's created by opening more than one project at a time, but it doesn't affect the VI itself. Libraries do affect the VI itself, because the VI knows which library it belongs to and it's something that sticks with it. That's real namespacing and the result is the fully qualified name which is made up of the owning libraries names and the VI names. You don't need more than that, because the FQN is only relevant inside the application instance (i.e. if you do an Open VI Reference, you need to give a FQN, but you also need to provide an application reference).
That was a bit stream of consciousness (I can never spell that word correctly) and I didn't understand the actual question, so hopefully it was clear enough.
Try to take over the world!