Lossy Enqueue into fixed size queue memory leak?

[Fedor]

I trying to implement a circular buffer using LabVIEW queue. My understanding is that if I Obtain Queue and specify a fixed max queue size, the queue would not use more memory than what is required to hold the said number of elements. I then use  Lossy Enqueue to keep just the fixed number of last elements in the queue. Nevertheless, the attached code quickly runs out of memory, which I can also see in Windows Task Manager. 

Do I misunderstand the mechanics of  Lossy Enqueue into fixed size queue?

LabVIEW version 2024.Q1

[mcduff]

Why is the obtain queue in the loop? I understand it is named, but I think that is the issue with your example code. If I move it out of the loop runs in less than 1s, keep it in the loop LabVIEW freezes.

[Fedor]

I want to pass the data between different parts of the application based on this excerpt from labview docs:

"Use named queues to pass data between two sections of a block diagram or between two VIs in the same application instance. If you wire name, the function searches for an existing queue with the same name and returns a new reference to the existing queue."  

The plan is to call obtain named queue in each section of the code and enqueue or dequeue  some data instead of developing overhead code to pass around queue reference. 

Perhaps the part "returns a NEW reference" provides a clue why this method eventually runs out of memory.

[mcduff]

Yes, new reference is key. From AI,

LabVIEW has a limit of 1,048,575 for the number of simultaneously open references of each type. This limit is due to the finite amount of memory LabVIEW uses to store references.Exceeding this limit can lead to the "Memory is Full" error, indicating a reference leak where references are not being properly closed. 

[andcadev]

Hello Fedor, 

please, post your VI in LV2023 format (or older).

[cordm]

You need one release for each obtain - unless you wire true to force destroy.

Obtain and Release Queue

How do you pass the queue name around? If you hard code the queue name on each block diagram, you have a hard time tracking its use. If you store the name in an FGV, you could just as well store the queue reference in it.

[Andrey_Dmitriev]

---

@mcduff wrote:

Yes, new reference is key. From AI,

LabVIEW has a limit of 1,048,575 for the number of simultaneously open references of each type. This limit is due to the finite amount of memory LabVIEW uses to store references.Exceeding this limit can lead to the "Memory is Full" error, indicating a reference leak where references are not being properly closed. 

---

It is actually also explained in Help: Obtain Queue Function — "If you use the Obtain Queue function to return a reference to a named queue inside a loop, LabVIEW creates a new reference to the named queue each time the loop iterates.", that is.

[Fedor]

Thank you all for the insight. I ended up putting a FGV-like wrapper around lossy enqueue to obtain and store queue ref in a shift register if the ref is not valid.

[Kevin_Price]

Just be aware that putting an FGV wrapper around your (lossy) enqueue function prevents parallel access to the enqueue function.  Different parts of code that *want* to enqueue at the same time will instead have to "get in line" for access to the FGV.

In your case with a lossy enqueue, execution should always be quite fast so the wait shouldn't be very long.  But keep the idea in mind in the future.  FGV's serialize access, a feature that can be used as strength.  But when used to wrap up a function that normally allows for parallel access, you can get some unexpected behaviors.

-Kevin P

[mcduff]

I use named queues in my loops for debugging purposes. You can use them without worry if used carefully and in parallel situations.

1. Use First Call and a FGV like construct.
2. If used in loop/VI that closes before the Main VI is finished, then use the Release Queue function to close the reference to avoid a memory leak. If the loop runs until the Main VI closes you can Force destroy all named instances that are open.