QSM query

[Kousy]

Yeah James,

At times the state machine loop goes thru race conditions.  Its not happening periodically. So I could not trace and fix it that's my real worry. That is why I wanted to know whether my coding went wrong anywhere.

Ben,

But without queue how can I send the user command from Event structure to the state machine loop?

Lynn,

You mean to say that use queues to send user inputs (using event structure) to main loop state machine cases. How could I insert from event structure to simple state machine case? That is how should I do ? : Add a simple case structure before extracting the current state from shift register to use it in state machine loop. In that case structure I can use the queue commands from the event structure to pass user events like start,  stop to simple state machine loop, Am I right?

Thanks

Kousy

[Ben]

The que can still be used to transfer the messages to and from...

My comment above had to do with the now defunct design pattern that uses a queue (or in the old days an array) to stack up states to be exectuted rather than the standard State Machine that has clearly defined states and the transitions can be stated at design time. That can not be done with a QSM. I have been trying to put together a good quote regarding the QSM that I will try again here.

"A QSM is the Worm Oroboros of software designs. it is a monster that is best managed by keeping it starved. If allowed to feed itself it will blow up."

Rather than multiply words let me share two links to threads form the past.

In this thread I show an old app that uses Action Engines to pass commands start and stop background processes etc.

The state diagrams show that I explicitly check for "stop" commands in the loop doing the work.

That thread also has images of a more upto date design where I take advantage of Dynamic Event Registration to allow State Machines (SM) within SMs, within SMs... to use an event to detect the stop button.

In this thread I posted some complete design documents that I put together before wire one was dropped.

One of the attachments in that thread labled "SystemArchitecture5.ppt" IF DOWN LOADED AND OPENED includes the diagrams of the many SMs and AEs but alos includes my notes to the developers explaining what I hadn in mind when laying out the design. That design by the way was implemented as designed with only one small change that affected how the Auto-Scaling for the Curve Tracer was implemented. The "Other Ben" on the project (the customers Ben) wanted it changed so some of the transitions wires got flipped around.

I hope that helps somebody.

Take care,

Ben

[johnsold]

Ben,

I like the quote!

Kousy,

I think you are on the right track.  The loop with the event structure can use queues to send messages (as Ben called them) or commands (as I often call them) to the state machine.  Each state needs to check for commands or messages as part of the process of determining the next state.  This can be described in the state and transitions diagrams Ben talks about, making this a true state machine.  Other transfer mechanisms such as Action Engines can also be used to transfer the messages or commands.  LVOOP may also be suitable, but I have not learned enough about it to comment about its usefulness.

The key point is that the GUI loop with the event structure does not directly set the state of the state machine.  It only send information which the state machine can use (or not) in deciding the next state.

Lynn

[Ben]

---

@johnsold wrote:

Ben,

I like the quote!

Kousy,

I think you are on the right track.  The loop with the event structure can use queues to send messages (as Ben called them) or commands (as I often call them) to the state machine.  Each state needs to check for commands or messages as part of the process of determining the next state.  This can be described in the state and transitions diagrams Ben talks about, making this a true state machine.  Other transfer mechanisms such as Action Engines can also be used to transfer the messages or commands.  LVOOP may also be suitable, but I have not learned enough about it to comment about its usefulness.

The key point is that the GUI loop with the event structure does not directly set the state of the state machine.  It only send information which the state machine can use (or not) in deciding the next state.

Lynn

---

Thank you Lynn!

Cation about LVOOP

Once you get used to it, you we feel like Spock from "City on the Edge of Time" (?) when he stated he felt like he was working with "stone knives and bears skins".

One of the inamges in in those linked threads is a VLOOP version. Genearlly characrterized by very clean looking code with wierd wires.

ben

[drjdpowell]

I should point out to Kousy and any lurkers that there is confusion produced by the badly-named "Queued State Machine".  A state machine is a specific computer science concept.  A QSM is actually a bad idea if you want an actual state machine, so experts in state machines strongly advise against QSMs.  However, you can instead view the QSM structure as a type of task handler, where requested tasks are broken down into a queue of subtasks.  If it was a state machine you wanted, drop the QSM structure as you've been advised.  But if you want a task handler, your current design has the problem that it might start task B before finishing all the subtasks of task A.

-- James

[Kousy]

I need to learn AE, LVOOP concepts. So I should go thru the links more than once to get the hang of it. Ill do it surely.

Basically I suspect my coding using qsm whether it is OK or it has a flaw. Now I understood a lot here.

If at all Im not using queues then by using simple state machine My application code will have 5-6 level of nesting. To avoid mistake and easy handling went for queued state machine. Now Ill need to re-design the structure to eliminate race condition.

Thanks for everybody's time.

 Kousy