Allow "Enqueue Element" and "Generate User Event" to handle arrays (atomically)

[drjdpowell]

This idea is that the Queue and User Event primitives be modified to allow arrays of elements/events to be enqueued/generated at the same time.  This is functionally equivalent to just indexing over the array with a for loop, but with one important exception: the enqueue/generation should be atomic, in that all elements/events should enqueued/generated without any intervening elements/events from other threads in the program.  So, for example, if one enqueues XYZ while another part of the program enqueues A, the queue will always either be AXYZ or XYZA, but never XAYZ or XYAZ.  And if there isn't room in the queue for XYZ, the enqueue will wait until there is room.  The idea is to limit the potential for intermittent bugs if the handling of A interferes with the handling of XYZ.

This idea was motivated partly by discussions, by Daklu on LAVA, of flaws in some "QSM" design patterns.

-- James

[tst]

This has already been suggested, at least for queues - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Enqueue-array-of-elements/idi-p/970556

[drjdpowell]

Darn it!  I had searched for "Queue" and "array" instead of "Enqueue" and "array".   Should have looked harder.  It that case, I second the previous queue idea and add User Events to the suggestion.

-- James

[SteveChandler]

I'm not sure it is a duplicate. The other idea does not mention atomicity even though the comments do. So these ideas are very close.

[G-Money]

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Enqueue-array-of-elements/idi-p/970556

[SnowMule]

Just wrap a for-loop around the enqueue element object?

[SteveChandler]

First you have to wrap the for loop. That is not a big deal but cosmetically it would be kind of nice if you didn't have to. But that is missing the main point of this idea - atomically. The guarantee that no parallel task enqueues something in the middle of the array.

I see that this is marked as a duplicate. I hope that if the original is implemented that it is atomic. Looking at the comments for that idea I am sure it would be.