Actor Framework Discussions

Showing results for 
Search instead for 
Did you mean: 

Handling "priority" message in actor framework

Go to solution

@BertMcMahan wrote:


You can stop the helper loop immediately if you want by adding a "sentinel" element. For example, say your queue data type is a string containing a database query. You know that no valid query will ever be an empty string, so you check for an empty string each time you dequeue something. If it's empty, stop the loop, otherwise wait on another element. This keeps your AF message queue separated, and in Stop Core you can send the sentinel value to the Dequeue function. Or I suppose you could just release the queue, then catch the error in your helper loop.


This seems to achieve identical functionality as the stop notifier you mentioned earlier, right?


@BertMcMahan wrote:


You can stop the helper loop immediately if you want by adding a "sentinel" element. ...

Channel wires have an actual dedicated feature to do this sort of thing but I haven't used those yet. I hear good things.

Huh, I wasn't aware of that functionality within channels. You talking about this (link)?



Please join the conversation to keep LabVIEW relevant for future engineers. Price hikes plus SaaS model has many current engineers seriously concerned...

Read the Conversation Here, LabVIEW-subscription-model-for-2022
0 Kudos
Message 21 of 23

It's the same overall functionality, I'm just saying you don't need both a notifier AND a queue. I've used notifiers before if I'm doing something like DAQmx that needs to be written over and over again. If I already have a queue, I don't need to add the notifier as well- I can do it with just the queue.


And I think that's the feature, yes. I thought it was called "Last write" or something but it seems like that's the one I was remembering. I've never used it myself.

0 Kudos
Message 22 of 23
Accepted by topic author WavePacket

@WavePacket wrote:

So @drjdpowell, your suggestion for an implementation might this then:

1. queries are sent to a helper loop via a queue

2. helper loop checks for stop notifier each time 

3. If a "priority" query comes up, load this into the helper loop queue at the front of the line

My motivation in these discussions about seemingly simple techniques is often the "hidden complexity" they can introduce.  And "enqueuing on front" for "priority" is an example of that.  Enqueue on front has hidden complexity in that multiple "priority" messages will have indeterminate execution order.  Put A, then B on the front of this queue and you do not know if they will execute A then B or B then A.  One of those orderings might cause a bug, yet happen rarely enough that you will not notice it in testing and deploy buggy code.  The worst possible bug.


Here's a better, seemingly more complicated but actually simple option.  It takes advantage of the fact that a Helper Loop has only one Writer sending it messages (don't use this suggestion with Actor Message Queues!):

3. When any task comes in:

  • Flush all tasks from the queue,
  • add new task to the array of tasks
  • sort the tasks by priority, with secondary sort by arrival time
  • enqueue (on back, note) all the tasks

This is actually simple, in use, as it preserves message ordering of tasks of the same priority.  AB is always AB; no race condition.  It's also a more powerful design, as you can have multiple priority levels, or do things like cancel individual tasks.

Message 23 of 23