LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dequeue Element always shows a buffer allocation even though it doesn't perform one

I've only experimented with a couple of cases, but it seems that Dequeue Element always shows that it makes a buffer allocation when the 'Show Buffer Allocation' tool is used.  I know that it dequeues in-place, so why does it show that a copy is made?

 

This is a problem for me as this might mask a case where it actually does make a copy (because of forks in wires or whatever reason after dequeueing) and the only way to detect this would then be to watch the memory usage before and after dequeueing (which defeats the purpose of the Show Buffer tool).

 

Or could it be that when a real copy is made that it will always show up as an additional dot somewhere later on the wire, and that the dot on the dequeue may safely be ignored in all cases?

 

 

 

 

 

0 Kudos
Message 1 of 13
(3,850 Views)

Hi Anthon,

 

Good afternoon and I hope your well today.


Thanks for the post.

 

I believe, but I am going to test this using the Trace Toolkit, that when you create a queue is sets up a chunk of memory - maybe you'll fit a couple of elements in. When you then enqueue more, it adds another chunk of memory. But, when you dequeue from the queue the size DOESNT decrease... I believe you have to flush the queue to reset the chunk number to 1 (as it were). Thus, the reason the dequeue is making a copy is because LabVIEW you needs to store that one element for manipulcation else where in your code.

 

What do you think?

Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help! 😉
Message 2 of 13
(3,846 Views)

Hi Anthon,

 

I just wanted to add that if you are concerned about carrying large datasets around you code then queues are a good solution. Create a queue with a single element that contains the data. Any time you want to access the data, dequeue the element. This will block other parts of the program from simultaneous access. Do the data operation. Then enqueue the element again. The only thing you need to pass around is the queue reference. In fact, if you name the queue, you can get a reference to it easily at any point by specifying the name in the Obtain queues function. Creating multiple data objects is as easy as creating multiple queues.u

Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help! 😉
0 Kudos
Message 3 of 13
(3,842 Views)

Thus, the reason the dequeue is making a copy is because LabVIEW you needs to store that one element for manipulcation else where in your code.

 

What do you think?


Thanks for your comments - however I'm really wondering why the dequeue is showing that it is making a copy when it is in fact not making a copy.  
I share your thoughts on the usefulness of single element queues for allowing efficient and controlled access to large datasets from many access points in your project, I've recently started using them and I have not been sorry!

 

0 Kudos
Message 4 of 13
(3,830 Views)

Hi Anthon,

 

Thanks for your prompt reply. I hope your well today.

 

The function IS making a copy of the element. 


The queue will remain in the same parts of memory as LabVIEW until it is destroyed - careless if you read from it or not. If you read from element 1, element 1 in the queue is still in memory, it just has 'no value'. BUT in order to use the value in the rest of your code you need the element stored outside of the queue to perform operations on it (as the queue could be written into at any point!).

 

I hope that made some more sense, please let me know otherwise I'll try and think of a better way to explain. 

Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help! 😉
0 Kudos
Message 5 of 13
(3,806 Views)

Hillman wrote:

 

The function IS making a copy of the element. 

 


 

 

Then consider the following code example where I have noted the memory usage as reported by Windows Task Manager at several points in the code.  

 

queueCopy.JPG 

From this it is clear that although there is a dot indicating a copy at the Dequeue vi, no copy is actually being made.  The data element is only created and memory allocated when it is initially pushed into the queue.  So repeated dequeue-and-enqueue pairs are very efficient at accessing data from several points in your code.  The dot just confuses me a bit but I can live with it. 

 

I understand your argument re what would happen if another process Enqueues another element into the queue when this one has been dequeued, it seems that the memory is allocated when the element is enqueued (note the dot on the first enqueue element call) not when it is dequeued.   

 

Message 6 of 13
(3,786 Views)
Hello AnthonV,

One point to stress in this thread is a buffer allocation is NOT the same as a copy. The buffer allocation at the dequeue element is LabVIEW creating space to store your data. This space is NULL until there is an element in the queue. There is space for one element in this buffer. When the value is taken from the dequeue element space is made for the next element.

The big thing to note, which you already discovered, is that we are not making copies in a queue.
Regards,

Jon S.
National Instruments
LabVIEW NXG Product Owner
Message 7 of 13
(3,756 Views)

Thanks Jon S, so you are saying that even though a buffer allocation is shown, it isn't an actual request for space to the OS (note Task Mgr doesn't show a larger allocation to LabVIEW from the OS's point of view)?  

 

Is it so that the request for memory only occurs when an element is pushed into the queue, but only if the data's (that is being pushed) original memory location cannot be used as-is for the queue element?  If it can be used, the queue element pointer is simply pointed to the already existing data's location?  

 

Sorry for the speculation on my part, its just that it helps to know what the underlying mechanism is when you are trying to ensure hard real-time determinism in RT.

 

 

0 Kudos
Message 8 of 13
(3,746 Views)

If you need hard real-time determinism in RT the right way to go is the RT FIFOs if possible.

 

Here's a comment from an NI employee in another thread that might help answer your question:

"If the buffer viewer shows a copy, it is not necessarily a full copy.  It may be only a pointer copy, especially if the underlying data object is something like an array or cluster (pointer based objects in C)."

0 Kudos
Message 9 of 13
(3,725 Views)

Thanks nathand, do you know of any resource that lists the pros and cons of using an RT FIFO (in comparison with a queue)?  From the help it isn't very clear.  

 

One thing I've noticed is that the RT FIFO doesn't accept a cluster if one of the cluster elements is an array.  I tend to use a cluster with several datatypes including arrays (of fixed size though) as a container for all the data I want shared across the project (as in the image in this thread above).

 

However, if there is good reason to rather use RT FIFO's I could use a seperate FIFO for the array... 

0 Kudos
Message 10 of 13
(3,717 Views)