Preview Queue Element with Index

[dgdgomez]

It would be possible to add to "Preview Queue Element" a new control indicating the index of the element to be previewed?

To be able to consult an element other than the first element inserted in the queue, it is necessary to use the function "Get Queue Status" and through "Index Array" to obtain the element you wish to consult. (See example).

My proposal is to add a new control to "Preview Queue Element" to indicate the index of the element that you want to preview, and using the 0 for the first element inserted, 1 for the second..., and -1 for the last element inserted.

[wiebe@CARYA]

What is the use case for getting a specific queue index?

What is wrong with the Get Queue Status? Well, the only problem I can think of is it will potentially return a large array, while you only want  maybe the first n elements. It makes more sense to me to add a max queue elements input to the Get Queue Status. (Return elements? could be an integer iso a Boolean. -1 is all, default 0 is none, any other integer specifies a length).

[dgdgomez]

A possible application would be the following:

In this example, the result of executing the code would be: A, B, C, A, B.

It is something similar to what we can find in the properties of the "Event Structure"

What is wrong with the Get Queue Status? 

- The problem is that it returns all the queue elements.

(-1) is all, default (0) is none, any other integer specifies a length?

- "Preview queue element" only returns one element, but you can get all queue elements with "Get queue status".

- By default it would be (0), and the behavior would be the same as currently shows.

- It is possible that we want to obtain the value of the last queue element, for that I propose to use the (-1). Although you could use "Get Queue Status" to know the number of queue elements.

[crossrulz]

In your example, I would just do a Dequeue and then a Preview Queue Element.  If the two match, repeat.  If they don't match, end your loop.  This would be at lot less code than what you are showing.

Any other use case I can think of for this feature would be severely plagued by race conditions.

[dgdgomez]

You make it complicated, but I will try to show another possible application, but in this case, we have to consider that we have "Lossy Enqueue Element At Opposite End".

In addition, we must consider that the implementation is not the one shown in the example of "Lossy Enqueue Element At Opposite End", since such implementation can produce race conditions. The implementation would correspond to what LabVIEW would provide, since it would have the control of the queue, either by "Semaphore", ...

The example consists of a queue of fixed size (in this case of 5 units), where you can keep the value of the last 5 states and be able to access its value.

Both threads of the code must produce the same result, in this case the value must be 4.

As you say, the race conditions are a problem, but in the end it depends on the type of implementation that takes place, in this case, it would be possible to eliminate the race conditions using a FGV.

[AristosQueue (NI)]

Speaking in my official capacity as Aristos Queue. 😉

The checkmark in the event queue works because LV can lock the entire queue for the duration of the operation. That is not possible for the queues (nor should it be possible as such higher level locking would inject significant performance penalties in all the ways I've ever seen proposed to do it). Therefore, adding such an index would increase the race condition abuse of these queue API.

> in this case, it would be possible to eliminate

> the race conditions using a FGV.

If you build an FGV around the queue for this operation then don't use a queue at all. Use an array of 5 elements and get significantly better performance without the refnum overhead!

[crossrulz]

>You make it complicated

How so?  You only need the one loop to remove consecutive duplicates.

[dgdgomez]

Sorry, maybe I expressed myself wrong, I was refering to propouse other use cases. The solution you propose is clearly and obviously uses less code, but it was only intended to indicate a use case at the conceptual mode.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.