NI Home > Community > NI Discussion Forums

LabVIEW Idea Exchange

Announcements
We've turned on a search before post feature in the LabVIEW Idea Exchange. This new feature will help cut down on the number of duplicate ideas in this space!

The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
PaulG.

Get Queue Status function return elements default is set to = F. Should be set to = T.

Status: New
by Active Participant PaulG. on ‎06-08-2011 12:14 PM

The Get Queue Status function will return all the elements in the queue - if you remember to set the "return elements" bool input to True. It's set to F as default. Why would I not want all the handy information from Get Queue Status but not want the elements? :smileyindifferent:

Comments
by Active Participant dthor on ‎06-08-2011 12:37 PM

Perhaps it has something to do with memory? I really don't know, I don't use queues as often as I should.

 

If it defaults to False, then I assume labview has to do less work when the program runs.

by Active Participant PaulG. on ‎06-08-2011 12:52 PM

I understand your point. Maybe it's my lack of understanding of how LV manages data output from primitives. However, the data are already present. And if you don't want the elements (and don't hook up a wire or indicator to the output) LV would not have to do anything differently.

by Knight of NI on ‎06-08-2011 01:22 PM

I'm voting for this because even though I'm already used to it, I agree that this is a mistake which is way too easy to make.

 

That said, if the change is made, then the primitive should have additional code which sees whether the elements output is wired or not and only takes the elements if the input is T AND the output is wired.

by Active Participant SteenSchmidt on ‎06-08-2011 02:30 PM

I often use the Get Queue Status to check if an element has been dequeued by the recipient (handshaking), or to monitor the number of elements to determine when to dequeue all elements (queue as buffer). In neither case do I want the elements themselves. Since the elements also remains in the queue, an actual data copy takes place if you use Get Queue Status to peek the queue. This can be expensive.

 

But the primitive should definitely have an internal check to save the data copy if the elements output isn't wired and return elements? is set to True (no matter the default value of return elements?).

 

Cheers,

Steen

by Member Wart ‎06-08-2011 02:31 PM - edited ‎06-08-2011 02:32 PM

I typically use get queue status to get the number of elements in the queue.  Then I compare this number to an outragiously large number and alert the user if it gets too large (i.e. something is wrong).  It makes for a nice bit of error checking in another loop.  I'm not sure I've ever changed the return elements input to true.

 

I agree with tst.  Ideally it seems like if the elements output is wired it should return the elements.  Otherwise it shouldn't.

 

Edit: It looks like SteenSchmidt beat me to most of these points.

by Trusted Enthusiast on ‎06-08-2011 08:08 PM

As the designer of the queue prims, let me chime in on this.

 

Copying all the elements in the queue is expensive. You have all the elements in the queue and you make a duplicate of all of them when copying out for the Status primitive. That takes time and memory which is undesirable if you don't actually want the elements.

 

If the terminal is unwired, obviously LV does not need to make this copy.  When we were designing those prims, our first design had that. What we found was that there were cases where someone sometimes wanted the elements and sometimes not, and deciding based on whether the terminal was wired or not was a poor solution because that meant dropping a Case Structure and putting two copies of the Queue Status prim, one in each frame, where one was wired and the other wasn't. Ugly. So we introduced the boolean terminal.

 

I don't have a clue why we picked False for the default value. I just don't recall. It's something that could be changed in future LV versions if we mutated existing VIs to compensate (it's a bit harder than just creating an input boolean to preserve the input value; we'd also have to do something if someone does have the elements terminal wired for some strange reason). If you wire the terminal, then you would get the elements by default, which does, I admit, seem more reasonable. This would not create any performance hit for anyone who left the terminal unwired since the terminal being unwired would still be a reason to not copy the elements.

by Active Participant Mads on ‎06-09-2011 02:10 AM

To me it makes perfectly sense to have it default at False. Most often when I use this function I want the que info, not the elements.  I would not want to spend any processor time or memory on generating that output when it is not needed.

 

The fact that you can get the elements out this way is not obvious enough to make users think that they should get it without any action. The compiler might rationalize the operation so that it would not matter if the default was true when the output has not been wired, but it is still logically cleaner to keep it at false.

 

I would agree that it would be useful to have a Preview function that returned all the elements though. Just remove that possibility from the get info operation (handle backwards compatibility the same way file operations did when they changed) and add a preview all function (or expand the functionality of the existing preview function (with a length input?)).

by Trusted Enthusiast on ‎06-09-2011 08:12 AM

Separating into two separate primitives opens the door to race conditions in those times when you wanted the full state of the queue.

by Active Participant Mads ‎06-09-2011 08:29 AM - edited ‎06-09-2011 08:33 AM

Yes you would not be sure that the state you read with the get status was still valid when you read the data.

by Trusted Enthusiast on ‎06-09-2011 01:19 PM

My gut reaction is no for one simple reason. Changing the behavior of these prims will alter existing code. I don't mind development functionality being changed. But when it comes to altering runtime functions it kind of spooks me. Aristos Queue's comments make me feel a little more comfortable about this particular one.

 

So kudos!

Latest LabVIEW Idea Exchange Blog Posts
About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Idea Statuses
Top Kudoed Authors
User Kudos Count
86
50
37
35
34