Actually, those two pieces of code are not necessarily identical. The person who writes the second version might expect that all the array elements are enqueued in a single operation without any possibility of another enqueue node running in parallel being able to insert into the array. Is that desirable? I don't know. Thoughts?
Good point AQ. I for one would expect the input array to come back out of the Queue as a block would not come out interspersed with other items. That is to say the lock on the queue is valid from the start of the array to the end. Just my 2c.
And what would you think about an extra VI in Queue Palettes which would be named "Enqueue Elements" and would only accepts an array of the queue datatype.
That way it shall be clear for the person wiring something to it, as Intaris said the lock on queue would be valid from the first to the last element of the array.
If another Enqueue Element(s) tries to enqueue something, it must wait the queue is unlocked, or its timeout.
In my opinion we don't need an extra VI.
If NI cant do it, do you think OpenG or something like that could? I tried to make it but it's difficult with a generic datatype.
I often do it with the For Loop to initialize my VIs, there are some functions in my Producer Loop to initialize my instruments, so I Enqueue them all at the beginning with that kind of array constant.
What would happen if the queue gets full in the middle of the enqueue (e.g. max queue size:10, queue has 5 elements, you try to enqueue 8)? If the multi-enqueue has to wait until the queue isn't full (which makes sense), then you would need a new mechanism to lock the queue behind the scenes only for writes. Personally, I feel it's not worth it even though the syntax is nice.
The "Enqueue Elements" will check Array size before to lock the queue, as I guess actual "Enqueue Element" does before adding one element. Returns an error if the number of elements is greater than the available space.
Enqueuing a single element does not return an error if the queue is full. It either waits until there is room (if the timeout is infinite) or it returns a Timed Out boolean (if the timeout isn't infinite and the queue was still full). Skipping the entire enqueue if the queue is full seems somewhat not in spirit with the queue concept.
The amount of syntax removed from the block diagram is only marginally beneficial, and it slightly reduces intuitiveness of the block. Looking at my code where I'm enqueueing from an array, I couldn't even use this... the array is built from within a For Loop, meaning it's a freebie just to drop a "vanilla scalar" Enqueue in the loop.
> The amount of syntax removed from the block
diagram is only
> marginally beneficial, and it slightly reduces
intuitiveness of the block.
On the other hand, if the array is large and the implementation locks the queue for adding of all the items, the performance benefits would almost certainly be substantial. You would eliminate all of the interim lock/unlock calls, the resolution of the refnum to underlying queue, and any necessary buffer reallocation would only happen once.
The handling of the bounded queue is certainly an issue. If we decide the value is "wait for space", we still need to define what happens if the array is fundamentally larger than the bounded queue.
Message Edited by Aristos Queue on 08-24-2009 05:56 PM
I think that enqueuing multiple items like this would be a great idea - especially if the queue gets locked for the duration of the activity. Its often the case (at least with our code) that an action/event requires several discrete actions to be carried out (of which its nicer to keep them alll in separate states) and as such we almost all end up with subVIs to do exactly this (with the obvious drawbacks of locking, etc for each and every enqueue plus the chance of someone else enquing half way through the desired result).
With regard to bounded queues, surely it would make sense to either wait until the items will fit (considering timeout value) or, if the items will never fit, to output an error (and if it errors, enqueue none of the items)? My thinking is that this kind of VI should treat the array as a single data element - either the whole array will fit, or it wont.
