Dequeue Element From Opposite End

[User002]

Like "Dequeue Element", but removes and returns the element in the back of the queue instead of the element in the front of the queue.

Like "Enqueue Element At Opposite End", but dequeues instead of enqueues from the opposite end as normal.

This would allow queues in LabVIEW to be used as double-ended queues (also called dequeues or deques, pronounced "decks"). It is already possible to enqueue elements on either end of a queue. It would make sense to also be able to dequeue elements from either end of a queue. 

It would also allow queues in LabVIEW to be used as stacks without having to use "Enqueue Element At Opposite End", which is useful when it is easy to modify consumer code but difficult or undesirable to modify producer code.

[AristosQueue (NI)]

Summary: This request was fully considered and rejected in the design of the queue primitives in order to have better performance for  the other queue operations.

Details: The data structure underlying the queues does not support this operation in order to be more efficient. Enabling support for the backend dequeue would make the other operations less efficient (the back end would need to have the ability to wake up sleeping threads to trigger waiting enqueues into a no-longer-full queue, creating contention between the front and back of a queue). We made the decision to not have the backend dequeue when the queues were designed for LV 6.1. It is a conscious functionality-vs-performance tradeoff. Given that the queues remain one of the highest-speed transfer mechanisms in LabVIEW between sections of code and are regularly used in very tight loops, this is not a tradeoff I would feel comfortable reversing, even considering modern CPU performance advances.

--- Aristos Queue

      Lead architect and developer of LabVIEW's queue primitives

[Darren]

Declined for reasons listed in AristosQueue's reply.

[User002]

Those seem like good reasons to decline this.

I thought about it and talked with a coworker, and it seems like it could be possible to implement a double-ended queue with a DVR that holds an array of the data type and keeps track of the indices of the front and back of the queue. Is there a way for a developer like me to make a container class like that which adapts to the data type it is constructed with? I'm thinking something like malleable vi's, but I don't think new DVR or delete DVR can be used in malleable vi's.

[AristosQueue (NI)]

Yes, malleables are the right tool for a type-flex job like this.

LV 2020 (releasing in May) fixes the issue with New and Delete not being allowed in malleable VIs.

You can do it with an array in an uninitialized shift register, and arrays can already be in malleable VIs. There's ways to make it work, but not straightforward.

You could also create a new channel type that enables writing at both ends. Channel templates are entirely written in G code -- you can find them in the "resource\Channels" directory. We don't have any good published documentation on making your own channels (I really want to get on that some day), but if you start with an existing template (in your case, Stream), and copy it to a new directory (name it "Deque Stream" or something similar) and rename the VIs inside it accordingly, you should be up and running pretty quick. After that, it's just a matter of changing the code to add a new terminal to the Write endpoint (for "beginning?") and adding the handling of that terminal in the core.

[User002]

Great! Thank you.