Send Queue Flush?

[JonJay]

I understand the concept of wrapping the Send Queues so they can only be enqueued by callers and only the owner can dequeue, but what about flushing the queue? I've come upon an instance where I need to flush the current queue and apply only the Stop Message... essentially an emergency stop that it needs to forget about what it was doing and shutdown. The only want I can think of how to do this is by flushing the Send Queue and then enqueueing a Stop Message. This could be done by adding a Flush method to the Send Queue but that breaks the paradigm that only the creator of the Queue can modify or dequeue Messages. Is there another way to do this that I'm not thinking of or do I just have to add a Flush method and make sure only to call it in situations like an E-stop?

[AristosQueue (NI)]

Flushing the queue is not a supported operation because it cannot be demonstrated to be safe.  We are modeling every command as we admit it to the framework to ensure that it doesn't open up any lurking bugs, especially deadlocks and race conditions. "Flush" has a problem in that if a Stop message or Error Report message is already in the queue and someone flushes the queue, critical information is irretrivably lost. Similar problems exist with any sort of priority queue or enqueue at front situation, where repeated posting of high priority or front-of-queue messages starves other critical messages from ever being heard, and there's no way to guarantee that messages sent from one sender are actually heard by another.

In your particular situation, you've flooded the queue with N messages and now are trying to send the Stop message and get it handled in a reasonable amount of time. One strategy that works is to make the handling of each message faster. Rather than synchronously handling the messages as they arrive in the Do.vi, have the Do.vi hand off processing of those messages to the processing loop in your Actor Core.vi so that you very quickly clear the receive queue itself. Another strategy is to reduce the flood of messages to the receiver so that there are many fewer messages, but that's often not feasible.

In Internet protocols, no particular data packet gets priority over any other unless the ISPs start doing data shaping. That data shaping creates all sorts of nasty problems for data, and it seems that the network scales best when all messages are treated as equal priority. This is an area that I am particularly NOT knowledgeable about, so I happily defer to anyone else who can comment more coherently on the subject. But based on what I know in that domain, my current line of thinking is that it is better to adapt the actors than to adapt the message queue.

I'm definitely open to suggestions on this topic.

Now, obviously, at the end of the day, you've got an application to write. If you find that the best way to actually get your system up and running is to add a Flush method, go for it, but do so with full awareness of the dangers and, yes, make sure you use it sparingly. OH... very important... make sure you protect yourself against the following race condition!!!

You write a Send E-Stop Message.vi. That VI does a Flush Queue and then Enqueue the E-Stop message. The problem is that after you Flush the queue, other threads may beat you to the punch enqueueing messages, particularly if some sender somewhere is flooding the queue regularly (which is probably why you're trying to do the flush). As a result, your E-Stop is still not at the front of the queue.

To deal with this, you'll need to add a Semaphore refnum into the Send Queue.lvclass private data along side the Queue refnum. The "Enqueue.vi" function will need to acquire the Semaphore, do the enqueue, then release the Semaphore. Then you'll add a new function "Flush Then Send.vi" which also acquires the Semaphore, does the flush, does the enqueue, then releases the Semaphore.

I can't think of any immediate dangers other than that one, but since I already know Flush isn't a safe method to admit, I haven't gone searching for an exhaustive list of all the issues with it.