BreakPoint

cancel
Showing results for 
Search instead for 
Did you mean: 

Queued State Machine pro and contra, snakes eating themself, suggestions for better programming designs, etc...

Interesting set of discussions.

 

I have a set of points I like to obey in my code (I haven't gotten around to finalising all of them yet).  My terminology may be wrong for some of these things, I am a chemist by "trade" and anyone familiar with my posts on the Forums knows that I get my terms mixed up a lot.... Sorry in advance.  I have a series of points I'd like to make but I'll split them up into separate posts because it ends up being a lot of information.  As per ususal, if I'm being stupid in my posts or making a complete mess of trying to explain something, please tell me as quickly as possible.  My intent is not to waste anyone's time.

 

1. Public vs Private Queue vs Priority Queue.

Processes which share a single command queue for external and internal inputs have a LOT of problems with sub-state ordering.  My initial solution for this is a "Priority Queue", "Private Queue" and a "Public Queue".  My process loop then always checks the Priority queue first.  If there's a Priority message, do it.  If empty, it checks the Private queue.  If there's a Private message, do it.  If empty, check the Public queue.  If there's a message from Public, do it otherwise wait and then re-check the queues.  All internal states can enqueue ONLY to the Private Queue.

 

This allows me to completely separate out external commands from internal commands.  I can then implement "macros" for external commands with arbitrary granularity (lots of linked states with minimal workload or a few states with significant workload however I feel at the time) and they are guaranteed to complete before the next public command is received.  This was good for a while.

 

Then I realised that, while this 2+1 (I consciously list the "Priority" queue separately) covers most cases, sometimes a state which was called inernally wants to queue up other sub-states and still guarantee execution order.  We now arrive back at the original "Insert" or "Insert at front" problem.  Essentially, instead of a 2+1 hierarchy, an N+1 hierarchy would be better.  By implementing an N-depth queue hierarchy for the "Private" Queue, EACH macro state (state which enqueues other states internally) creates a new queue (Q+1).  Execution of the old queue is suspended while this new queue is processed.  Should one of THESE states again enqueue more states, then this Q+1 is suspended and Q+2 takes over.  Only when Q+2 is finished do we fall back to Q+1.  This behaviour allows us to implement internal states with a truly arbitrary level of complexity.  It is essentially a recursive Queue.  In this way we can mix and match "normal" states and "macro" states at any point in the command Queue and execution order will always be the same.  Yes, the execution order may be complex, but it is constant and finite (unless there are states which keep inserting new states indefinitely.....) for any given external impulse.

 

I have dabbled with the composite pattern (See GoF) to implement this and have made proof of concept for both Queues and User Events.  While making an arbitrary depth Queue was hard enough to conceive, mMaking User Events work with an arbitrary "depth" of independent command queues was even more challenging at first but it is actually completely possible and seems to work just fine (barring a false compiler optimisation which requires an "Always copy" to fix).  Apparently NI did not think anyone would try to do what I did with registered event refnums.......  A non-LVOOP approach is simply using an array of Queues (or of course a Queue of Queues) as command queues, adding to the end of the Array as required and re-sizing the array when the last queue is empty.  This way every state which enqueues other states adds the states to its own new Queue to the end of the array.  Execution order is always guaranteed.

 

One word at the end.  Typically the code which interfaces with any such processes of mine do NOT have the option to send command objects (composite or not) directly.  I tend to work with a much pared-down external interface.  This means I KNOW what the execution order if of any given external command.  Maybe it's just me but this reduces the complexity of the state management from something which is essentially infinite to something which is at least finite and constant, even if it IS complex.  I also know that no external code can sneak in any disk activity, abort commands or other shenanigans which may wreck my day.  I'm happy to see there are others who seem to share this idea.  This is perhaps the main reason why I have an academic aversion to the Actor Framework.

Message 11 of 17
(7,122 Views)

@Ben wrote:

@JÞB wrote:

Strangly enough, (or perhaps it is serendipity) I ran across these sources today.

 

I'm not going to summarize them but, let a few guys say their own piece.  Which I found rather enlightening.

Jon has a good inside-out take on the subject that I think addresses the oroborus issue Just give me the data I know what to do!

Dimitry explains Why

 

I Still have a few strands of duct-tape in place holding my brain together.  And AN SHRUBBERY to unpack! its here!


I think you should expand on why and how that bolg post fits in here Jeff. Please "throw us a bone".

 

(smiley-wink)

 

Ben


I think I should expand on that too....  The Duct-tape is off but, Give my poorly organized brain a little time.

 

As a teaser,

<Sea Story>

Back in my Navy days (When I was instructing Noah on Ship Handeling- poor student- bad parking job) I once took my Division Officer asside and had this conversation

DivO: Jeff, "Do This"

Jeff: What is the problem?

DivO: The Problem is "XYZ is underperforming" and it will affect the Ships "Yada" capability

Jeff: No, sir, I need to "Do That" not "Do This" to fix the "XYZ Performance" Tell me what the trouble is, I'll figure out the solution!

 

The gist was the Executive should focus on what opportunities are present or may be present in the future and assign priority, Depend on the trained and knowledgeable workers to provide Solutions now

</Sea Story>

Yet, something is resonating there and, I'm sure it has a LabVIEW application Thanks Jon


"Should be" isn't "Is" -Jay
0 Kudos
Message 12 of 17
(7,116 Views)

@JÞB wrote:

...


I think I should expand on that too....  The Duct-tape is off but, Give my poorly organized brain a little time.

...

Yet, something is resonating there and, I'm sure it has a LabVIEW application Thanks Jon

 

 


I will be on vacaton as of 2:00 PM eastern and not be back until after the new year. Use some "Goo-Gone"

 

 

to deal with the residual adhesive left over from the duct tape, and I will look for a nice clear explanation from you when I return.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 13 of 17
(7,107 Views)

@JÞB wrote:

<Sea Story>

Back in my Navy days (When I was instructing Noah on Ship Handeling- poor student- bad parking job) I once took my Division Officer asside and had this conversation

DivO: Jeff, "Do This"

Jeff: What is the problem?

DivO: The Problem is "XYZ is underperforming" and it will affect the Ships "Yada" capability

Jeff: No, sir, I need to "Do That" not "Do This" to fix the "XYZ Performance" Tell me what the trouble is, I'll figure out the solution!

 

The gist was the Executive should focus on what opportunities are present or may be present in the future and assign priority, Depend on the trained and knowledgeable workers to provide Solutions now

</Sea Story>

Yet, something is resonating there and, I'm sure it has a LabVIEW application Thanks Jon


I like the story, and I think you were acting as a good actor (QSM?) Jeff. Your division officer doesn't need to know the specifics of every fix but they know that XYZ is a problem. You were the specialist for XYZ so DivO should just tell you there is a problem and assume that you will act on that information appropriately (hopefully by fixing it).

 

 

DivO was acting as a QMH, XYZ is a problem so it will send a command to another person/process. It's easier and probably worked for a while until part of the process changes and "Do This" no longer fixes the problem or you don't even recognize the command anymore.

 

Also, thank you for linking Jon's blog. I have not seen that blog before but really like what i've read so far.

 

Matt J | National Instruments | CLA
Message 14 of 17
(7,084 Views)

@Ben wrote:

@JÞB wrote:

...


I think I should expand on that too....  The Duct-tape is off but, Give my poorly organized brain a little time.

...

Yet, something is resonating there and, I'm sure it has a LabVIEW application Thanks Jon

 

 


I will be on vacaton as of 2:00 PM eastern and not be back until after the new year. Use some "Goo-Gone"

 

 

to deal with the residual adhesive left over from the duct tape, and I will look for a nice clear explanation from you when I return.

 

Ben


Ben, during a vacation I would look for a bit different "residual adhesive removal"... yes, I have to admit, even after a few years I am still 100% amazed by the German engineering: and I am not talking about car making 🙂  And I am still not speeking their language...but no problem with their beer (to finish) 😄

 

DSC_0198_mod1.jpg

 

 

 

 

 

 

 

0 Kudos
Message 15 of 17
(7,063 Views)

After one of my managers returned from a road trip to a customer that has been weaned on a QSM, he wanted to review with the team here why we don't use a QSM. Lots of reasons given and those that have been burned by QSM's gone wild, a very zealous conversation.

 

I walked away thinking;

 

"

I invoked the words of Dijkstra twice, and once each Plato's Republic, Monty Python Quest for the Holy Grail and Mary Poppins... not bad.

"

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 16 of 17
(6,334 Views)

@Ben wrote:

After one of my managers returned from a road trip to a customer that has been weaned on a QSM, he wanted to review with the team here why we don't use a QSM. Lots of reasons given and those that have been burned by QSM's gone wild, a very zealous conversation.

 

I walked away thinking;

 

"

I invoked the words of Dijkstra twice, and once each Plato's Republic, Monty Python Quest for the Holy Grail and Mary Poppins... not bad.

"

 

Ben


Speaking of Dijkstra,  did anyone ever answer the question "which discipline is more respectable?"Smiley LOL


"Should be" isn't "Is" -Jay
0 Kudos
Message 17 of 17
(6,209 Views)