07-12-2013 08:46 AM
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.
07-12-2013 09:34 AM
You certainly don't *need* to name it. It works fine even if you don't. In fact, there's also a definite advantage to not naming it - if you name it, you create the possibility of another place in the code accessing the same queue on purpose or accidentally, which is sometimes desirable, but sometimes isn't. Essentially, I would say that if you want to access it from multiple places and you don't want to pass it using a wire, then name it. Otherwise, don't.
There is one other advantage which might be gained from naming. If I'm not mistaken, the execution trace toolkit allows you to see queue names. This can be useful during debugging because it would make much clearer which data is going through each queue.
07-12-2013 10:23 AM
In the Queued Message Handler project template, we purposely do *not* name the message queue, specifically for the access collision reason that tst cited. All queue communication and branching is explicitly specified by the developer in the form of routing the queue wire to various loops. The same goes for the Continuous Measurement and Logging sample project, which has several queues.
07-12-2013 10:50 AM
@Eric1977 wrote:
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.
Named vs Unnamed queues:
Leaving the queue unnamed forces future developers that may be adding funcionality to create a defined interface to access your QMH rather than just jambing commands in through the back door ("spaghetti queues" can be awefully bloated) So the common "Best Practice" is to not name them in broadly defined application areas. Think "Plant" or "Enterprise" applications. In narrowly scoped applications like "Test" the advantages naming queues for debug, rapid development of small scale solutions, and ease of integration make the named queue actractive.
Enums vs Strings:
Strings can be localized - Enums cannot. a major point to consider and the justification NI R&D offered me for the choices made when developing the project templates. Look into those project templates for examples you might not have seen before.
07-12-2013 10:53 AM
Just to clarify, the strings used in the message queues in the project templates are not localized. Rather, strings were selected over enums to allow for a unified message queue API to be used across all message handlers.
NI Week plug: I'll be discussing, in much greater detail, the decisions behind the design of the Queued Message Handler project template in my "Queued Message Handler: Caveats and Design Decisions" presentation on Thursday of NI Week, at 10:30 AM in room 16A.
07-12-2013 12:34 PM
Thanks Guys,
The reason for it was that in a lot of the queue posts, I believe Mark_Y always stressed naming the queues (or at least that is the impression I got from reading his posts). Maybe he could shed some light of this, if he wishes.
07-12-2013 01:01 PM
@Eric1977 wrote:
Thanks Guys,
The reason for it was that in a lot of the queue posts, I believe Mark_Y always stressed naming the queues (or at least that is the impression I got from reading his posts). Maybe he could shed some light of this, if he wishes.
Again it comes down to bredth of scope. The Templates are tools for making anything. VERY broad Build a lot of soultion from the tool and eventually two developers are going to use the same name. Just like having two vi's with the same name LabVIEW could never tell them apart and bad things happen. by appling "Scope" to vi's with projects we can get away with things like "Init.vi on Instr1.lvproj" and "Init.vi on Instr2.lvproj" but Queues belong to the application instance. So, if both instrument divers "Init.vis" relied on a "Talk" queue there would be no way to use both at the same time. (Instrument drivers being another example of a "Broad" scope use case)
On the other hand assume you are writing code to build into "Test gizmo.exe" and you want to build some messaging loops to hold pieces of the application together. Named queues are quite attractive here since the application bounds the scope of the queue.
07-13-2013 01:30 PM - edited 07-13-2013 01:32 PM
@JÞB wrote:
by appling "Scope" to vi's with projects we can get away with things like "Init.vi on Instr1.lvproj" and "Init.vi on Instr2.lvproj" but Queues belong to the application instance.
Just to clarify - project = application instance, so queues between different projects won't mix even if they are open at the same time (unless you're running LV 8.0 where there was a bug which allowed this). To make the analogy correct just replace the lvproj with a class or library.
As far as right or wrong goes - it's neither. There are places where it may be desirable and places where it may not. It's up to you to be aware of the usefulness and dangers and decide on a case by case basis. For me, there is usually no use for naming the queues, so I don't, but that could change, for instance, if I was dynamically generating hundreds of queues and wanted to access them using a specific kind of logic.
07-13-2013 03:22 PM
@tst wrote:
@JÞB wrote:
by applying "Scope" to vi's with projects we can get away with things like "Init.vi on Instr1.lvproj" and "Init.vi on Instr2.lvproj" but Queues belong to the application instance.Just to clarify - project = application instance,
??????? I know you know things I do not know. FQN vs. Namespace? in the IDE or a built Application? Really what are the differences? Scope is one of those details I'm interested in but, do not have enough education to stand on. You probably do!
I just make things work and try too understand as best I can
.
07-13-2013 03:59 PM
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:
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.