Difference between QSM and QMH?

[LV_COder]

What is Difference between QSM and QMH?

Hemant

[Gregory · Accepted solution]

Hi Hemant,

This has been discussed here as well as extensively on LAVA. Some of the definition is personal opinion as well, but here is mine. 

Queued State Machine (QSM): Actions are put onto a queue and executed by the state machine. The state machine itself can enqueue new actions (state transitions) based upon state logic. This is kind of like a wind up toy, where you wind it up, put it on the table, and you expect it to move around for a little bit until it stops. However, it could move around forever, or it could fall off the table.

Queued Message Handler (QMH): Actions are put onto a queue and executed by the message handler. The message handler itself cannot enqueue new actions. This is like your loyal butler, Jeeves. If you ask Jeeves to do something, he will do that and only that.

Either of these could be abused by the programmer. Just try to stay in the mindset of having your processes be small, discrete, actions that can be easily interrupted if need be. 

[Bob_Schor]

Note that NI, in their Tutorial on the QMH, specifically says that the Message Handler can send messages to itself, which as GregoryJ mentioned, can cause trouble.  Good Rule of Thumb is to remember IBM's famous one-word (5 letter) Motto ...

Bob Schor

[crossrulz]

---

@LV_COder wrote:

What is Difference between QSM and QMH?

---

Kind of just reiterating what Greg already stated:

QSM - State Machine that holds a series of states to be ran in a queue.  The JKI State Machine is a form of a QSM, it just uses an array of strings (or is it lines in a string?  Been too long since I really examined it) to hold the states.

NOTE: It is really bad if other loops have access to the state queue.  Use other means (another queue, user event, notifier, etc) to send messages to a QSM.

QMH - Loop that runs in parallel with the main loop that does one specific job when another loop tells it to do something.  For me, these are commonly log or instrument handlers.

NOTE: It is really bad if a QMH enqueues states onto itself.  Race conditions ensue.

[piterx]

I'm sorry about reviving fairly old thread, but this QSM, QMH haunts me since I failed my CLD exam (when my program hunged eventually due to repeatedly enqueuing Idle case using in NI shipped template for QMH)

I don't understand how a QMH cannot enqueue states. If not then what enqueue new states.

My superficial understanding of QMH is that we have an event handling loop, (which I like to use to decouple GUI from the logic, as a process can take some time to finish and we need GUI to be responsive. I know it might not be always the case in real application, but CLD exam is my current goal) and Message Handling Loop where I like to place all the logic.

If stated like that I cannot understand two things:

If Event Handling loop can't access the states (messages) queue than how do you communicate with the main loop? If QMH cannot enqueue states into itself then how to handle all the logic?

And why NI states that is acceptable to enqueue states in QMH if it's not acceptable according to you guys?

What am I missing?

Many thanks

[crossrulz]

A QMH is reactionary.  It just does what it is told to when it is told to do it.  So it is depending on the main loop to tell it to do something.  Now, a trick I commonly do is use the Timeout feature of the queue.  I store the timeout value in a shift register so I can adjust how long the Dequeue can wait for a message to in.  Set it to -1 to wait forever; set it to some positive value to allow a timeout.  So on timeout, do your state machine logic.  This way you are constantly checking for messages, but you can also implement a state machine.  I recommend avoiding a QSM mixed in with a QMH since it will be easy to mix up the queues or accidentally leave states in the QSM queue.  Doing a simple State Machine will work just fine.

So by doing it this way, the QMH is not enqueuing messages back onto itself but it is still maintaining its own state.  Again, the state of a QMH should not be visible to anything outside of it.

[drjdpowell]

Unfortunately, the terminology has lost its usefulness, and "QSM" is a particularly bad term as it isn't actually a State Machine.

[drjdpowell]

Ignoring terminology, your.. uh.. loop structure thing must:

• Handle information coming from outside itself, be that messages or events or just time passing
• Execute tasks as divided into subtasks or subactions

Designs that try to mix these two things get into trouble, with the common problem being sending subtasks to yourself as messages.

[BertMcMahan]

I'll offer a dissenting opinion on the "QMH should not send itself messages" statement. The Actor framework is basically an advanced QMH (it has a queue of messages that it handles) and Actors send themselves messages all the time.

The problem is with the QSM, which (like stated above) is not a real state machine, and is an architecture that (IMHO) should not be used for most cases. If you're queueing "states" (i.e., sending some state command that executes the same piece of code each time it's sent, regardless of the status of the rest of the VI), then you should just use subVI's to do that. If you're sending "states" that depend on previous values in the system, then... you're not sending "states", are you? At that point, you're sending messages that execute based on the previous state of the system, which is a QMH. Whether the "state" saved internally to the loop is a specific enum (recommended) or just evaluated on-the-fly (e.g., a system with just a couple states that depend on being above or below some analog value) it's still not queueing up *states*, it's queueing up *commands*, aka messages.

This could seem a bit pedantic but I think it's important. You absolutely do NOT want to enqueue **states**. A "state" is a label for the current status of a system; not a task for it to do. For example, a garage door might have states of "Currently open", "Currently closed", "Opening", or "Closing". Commands to this system might be "Open" or "Close", which can be queued up. What the garage door DOES on each command is dependent on the current state. An "Open" command would do nothing if the current state is "Currently open" or "Opening". If the current state is "Closing" or "Closed" then the state would transition to "Opening". The outputs change on state transitions.

I want to say again, if you're enqueuing *states* then you run into race conditions and complexity that doesn't need to be there. A QMH is a wonderful, useful tool to have in your architecture toolbox. A QSM is a dead end that might have some useful corner cases, but is a bad idea in 99.9% of all use cases (maybe 100%).

One last clarifying point to define my terms: the difference between the QMH and QSM is where the state is stored, not whether or not they use queues. A Queued Message Handler can have a State Machine and use Queues, but it's different than what's commonly called a Queued State Machine, which uses a queue to hold states, and is generally something to avoid.

[Kevin_Price]

Just to give another angle on how to *think* about differences between state machines and message handlers, I'll quote from myself over here.  (Note that I agree with the advice against queueing up states even though that isn't apparent in the following quote.)

Some essential concepts to distinguish a Queued Message Handler from a Queued State Machine:

- In a QSM, a case and its code define a state.  States are what get queued up.  A QSM will tend to linger within a state (or loop around to the same state repeatedly).

- In a QMH, action messages get queued up.  Code for a message will execute quickly.  A QMH will tend to linger at the Dequeue function, waiting for a message to act on.  Data is what defines the operating state, usually held in a typedef'ed cluster and stored in a shift register.

-Kevin P