LabVIEW
porblems with queues and notifiers as members of a cluster
Queues and Notifiers are already passed as references. You should have no issues on them being in clusters. I suspect you are having lifetime issues, but we really need to see code to evaluate issues you may be having.
Queue variables are references to a queue. Variables passed to subVI's are by-value, but the value of a queue variable IS a reference, so you will not duplicate the queue when you pass it down.
The risks with this is managing the lifetime of the queue. If you obtain a queue then split the wire it generates, then releasing the queue on EITHER wire will release the reference for BOTH wires.
Also, depending on what you are doing, you need to be careful splitting that wire. Queues are generally a "many to one" or "one to one" tool. If you split the wire and have multiple dequeues, then each enqueued element will only come out of one Dequeue Element function. This can be helpful if you want it to work that way- for example, you're crunching a lot of data and want to use parallel processes. However, if you want two different things to get copies of the same data, you can't use separate Dequeues to do that. (use User Events in that case).
If you're splitting the wire to Enqueue elements, then that's all fine. They will stack up in the order in which they're received.
One last thought, if you're dynamically launching subVI's, then sometimes references can get automatically cleaned up when the top-level VI that obtained the initial reference closes. I can't recall offhand if queues do this or not, but it's something of an edge case. Obtaining queues and using them in a different top-level VI context isn't something you're likely to do accidentally 🙂
@BertMcMahan wrote:
One last thought, if you're dynamically launching subVI's, then sometimes references can get automatically cleaned up when the top-level VI that obtained the initial reference closes. I can't recall offhand if queues do this or not, but it's something of an edge case. Obtaining queues and using them in a different top-level VI context isn't something you're likely to do accidentally 🙂
This is probably the single most issue encountered by intermediate users starting to write more complex applications when dealing with LabVIEW Refnums. Any LabVIEW refnum (both dark green as well as purple wires) is a reference to some underlying object. No copy of that object happens when you split a refnum wire nor when you open a new refnum to the same named object (when using names).
However, LabVIEW remembers in which top level hierarchy a refnum was created (open, create and similar) and when that top level VI goes idle (stops executing), all refnums created in the hierarchy of that top level VI are automatically closed. This is a sort of garbage collection.
If you happen to create a refnum in some VI hierarchy and then pass its refnum to another (usually dynamically started) VI hierarchy, that refnum gets "garbage collected" as soon as the first hierarchy gets idle, and is consequently also invalid in the other.
There are two approaches to avoid this problem:
1) Make sure that a refnum object is created in the hierarchy it is used, or keep the creating VI hierarchy running until it is not used in another VI hierarchy anymore.
2) For objects which allow names such as queues or notifiers, obtain an explicit refnum by name in every VI hierarchy. The two (or more) refnums still reference the same object but are individual refnums that each are registered to their respective top level VI hierarchy and only that respective refnum gets collected when one of the top level VIs goes idle. The actual object uses internally reference counting to remember how many individual refnums are referencing it and the object only gets destroyed when the last refnum is collected or closed.
So, since queues should work in clusters, I put the queue back into the cluster and got the error below when I try to act on the queue. I don't get any error when I try to create the queue. I don't have any problems when I create the queue outside the cluster and use the external version. Any ideas?
@Jim12345678 wrote:
I don't get any error when I try to create the queue. I don't have any problems when I create the queue outside the cluster and use the external version. Any ideas?
Not really without seeing the actual code, and I don't mean just the VI where you put the refnum in a cluster but also where you use it and how the two routines are related and get started.
My bet is still on that you are creating the refnum in a different top level hierarchy than where you try to use it. Personally I'm anyhow not a big proponent of putting all this stuff into big dinosaurs clusters.
Another point: your "read local, update element in cluster, write back to local" only is NOT a race condition if there is a 100% guarantee that nobody else in your program can at this point do a similar read/modify/write cycle on that same local. Basically, use of a local in such a way is exactly the same than if you used a global, the global just gives other VIs a chance to mess with the contents too, so amplifies the race condition problem.
Can you post all of your code? I would agree that the problem here is likely local variable related. I bet you're either reading the "Camera 0 Settings" local variable before it gets written (accidentally).
Another possible idea, are you using "Force destroy" on a duplicate wire somewhere? You're using named queues, meaning you CAN have multiple references to them, but if you use "force destroy" on one reference it will invalidate all references.
