A few weeks ago, I posted my Priority Queue implementation. It's gotten good reviews. At the time I lamented that I could not provide a bounded priority queue. I have now resolved those difficulties.
Here is the Bounded Priority Queue class saved in LV 2011. Note that it does NOT inherit from the Priority Queue class. It is a completely separate implementation. I expect my reasoning for this to be somewhat controversial among those who analyze API design philosophies.
The queue refnum built into LabVIEW has a single data type that supports both bounded and unbounded behavior. If I want to change from an unbounded queue to a bounded queue or vice versa, it is a simple matter of tweaking Obtain Queue and no further changes are needed downstream. In this implementation, I have created a new class for Bounded Priority Queue. This means that switching from unbounded to bounded means replacing the class all throughout your application. That is an acknowledged downside to my choice.
My reasoning for the split came down to the Enqueue Element function. In the unbounded queue, Enqueue Element does not have a "ms timeout" input or a "timed out?"output; the bound queue version has both of these. I decided I did not want to add those terminals to the unbound priority queue implementation since they would always be meaningless. Under the hood, the unbound priority queue code is cleaner because it doesn't ever have to worry about this possibility, making it ever so slightly faster. That decision lead me to make Bounded Priority Queue a separate class in a separate hierarchy. That had three nice side benefits for performance:
1. I didn't need an "if bounded" test of any sort in the plain Priority Queue.
2. The small bit of extra data that I had to allocate for a bounded queue wasn't needed by the unbounded queue.
3. None of the VIs were made dynamic dispatch
These are fairly trivial performance benefits, I grant, but given the speed tests that are often demanded of queue implementations, I figured, what the heck.
Since I had split the classes, I made the "Max Queue Size" on Bounded Priority Queue:Obtain Queue a required terminal. That eliminated the always-kind-of-strange use of negative values as the indication for an unbounded queue.
Obviously, someone with a small amount of work could take the Bounded Priority Queue class and make it aware of itself enough to support unbounded behavior so you could have the simpler edit-time experience. I chose not to do that here. I am not sure if that means my thinking has changed since the design of the queue primitives eleven years ago or if it just means I decided to try something different. In any case, you now have a bounded priority queue to use in your G applications.
