Queue references in functional globals

[GregFreeman]

As long as I initialize the functional global (i.e. create the queues) in my main VI which will not leave memory until the program is exited, I should not have any problems with losing these references in the shift registers, correct? I have 9 VITs running that all need access to the queues.

I know there have been other posts on this, and I am still reading them all so forgive me if my question is answered already. If someone has a better way to manage this, please let me know.

Edit: My queues do have names, I just deleted them for this post.

 

[Ben]

LabVIEW's clean-up routine may be sneaking up and biting you.

If LV sees a hiearchy go idle all of the resources are cleaned-up (doing you a favor) so the numbers associated with the queue refs will still be in the SR's but the queue that those numbers point to will be smoke.

You have to keep the hierachy alive to keep the queue alive.

Ben

[GregFreeman]

---

@Ben wrote:

LabVIEW's clean-up routine may be sneaking up and biting you.

If LV sees a hiearchy go idle all of the resources are cleaned-up (doing you a favor) so the numbers associated with the queue refs will still be in the SR's but the queue that those numbers point to will be smoke.

You have to keep the hierachy alive to keep the queue alive.

Ben

---

I haven't tested this method, so I don't know if it will bite me yet :).

Suggestions for a better way to manage this?

[tst]

Like you said in the original post, if the queue reference was created in the hierarchy of the main VI and the main VI stays in memory until the very end, then you have no problem. That means you just need to make sure the queue is created in that hierarchy, which means running the FG before the VITs start running.

And an additional point:

Named references have another caveat - each reference is treated separately, so if you obtain two references to the queue and then destroy the hierarchy which obtained the first reference, the queue itself will not be destroyed (unless you set the appropriate input on the destroy primitive).