LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Opening/Closing Queue Reference By Name

I'm curious if opening and closing a queue reference to put information onto the queue, using the queue name -> obtain queue -> enqueue -> release queue(Non Force) is problematic.  I thought i saw a thread a long time ago that opening/closing a reference to a queue over and over could lead to a memory leak, even if the original queue never was released.  Obviously, i'm ignoring the general pass the wire(by value) correct labview way. 

 

Instead of opening/closing using the queue name i could also wrap the queue reference in a FG after originally creating it and work on the reference that way. Ignoring the "right way to do it" are there still downsides, other than programing correctly, to open/closing queue reference's in this fashion such as memory leaks.

0 Kudos
Message 1 of 6
(3,816 Views)

I have never heard of any unwanted consequences of repeatedly opening and closing any reference. The trick is to make sure a reference gets closed when no longer needed. I don't see any reason not to implement queues the ways you describe. I've done all three and haven't had any issues that I know of. If opening and closing a queue reference repeatedly caused a memory leak that would be considered a bug.

PaulG.

LabVIEW versions 5.0 - 2020

“All programmers are optimists”
― Frederick P. Brooks Jr.
Message 2 of 6
(3,803 Views)

I think the issue you're thinking of is that obtaining a queue reference by name doesn't get you the original queue reference, it gets you a copy of the reference. As you correctly stated you need to close that copy, which will not destroy the original queue. Many people expect that obtaining a reference to an existing queue by name simply returns the existing reference and don't realize it's actually a new copy, which does lead to memory leaks.

Message 3 of 6
(3,796 Views)

I'd say the opening and closing of a queue reference by name is too much extra overhead.  Each time you obtain a reference, a lookup is done and then a copy of the reference is made and then eventually cleared when you release that copy.

 

I use the Action Engine to hold all of my queues, notifiers, and events.  It gets initialized in 1 place (where the reading is done) and then anybody can call that VI to send the command/message/data.  I then make the reading VI destroy the queue.  No searching, copying, and clearing to be done.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 4 of 6
(3,794 Views)
Thank you all for the responses. I figured as long i was closed the ref i was ok but just wanted to double check.    

@nathand wrote:

I think the issue you're thinking of is that obtaining a queue reference by name doesn't get you the original queue reference, it gets you a copy of the reference. As you correctly stated you need to close that copy, which will not destroy the original queue. Many people expect that obtaining a reference to an existing queue by name simply returns the existing reference and don't realize it's actually a new copy, which does lead to memory leaks.


This is what i was thinking of.  I did not realize this was the case. I figured obtaining the reference was more of a pointer to the reference than a new copy of the reference.  Thanks for the info, i'll have to keep that one in mind, it makes sense i just hadn't really thought about it in those terms before.  
0 Kudos
Message 5 of 6
(3,790 Views)

@PaulG. wrote:

I have never heard of any unwanted consequences of repeatedly opening and closing any reference. The trick is to make sure a reference gets closed when no longer needed. I don't see any reason not to implement queues the ways you describe. I've done all three and haven't had any issues that I know of. If opening and closing a queue reference repeatedly caused a memory leak that would be considered a bug.


I have to disagree here. A couple of years ago I was using a DAQmx Write with "autostart" option set to TRUE in a loop (ca. 100ms timing) to constantly make sure, that in application standby my Digital Outputs kept the values they ought to have. This reproducibly caused a blue screen on Windows after 6 hours of the program running in standby. As it turned out, LabVIEW was using a new reference to the task for every call of the Write, because with autostart set to TRUE it had to create the task beforehand and close it afterwards. After the mentioned peroiod of time, LabVIEW ran out of reference numbers, as the support explained to me.

 

Of course, even LabVIEW Help says to avoid using autostart=TRUE with DAQmx VIs in a loop, but only because of the overhead the repeated Create and Clear is consuming. Naturally, I have learned that the hard way now.

 

So - Create the reference once, use that same reference all the time (FG is fine, I think - I use this method for obtaining my logfile reference all over the place!) and close it only, when you don't really need it anymore.

 

0 Kudos
Message 6 of 6
(3,763 Views)