What is the disadvantage of state machine?

[billko]

---

@crossrulz wrote:

---

@REAL! wrote:

Isn't a state machine with a queue a QMH?

---

Not quite.  There is a slight difference between a Queued State Machine and a Queued Message Handler.  They look alike, but the QSM handles its own queue to go through states while the QMH just accepts commands from other threads through the queue.

---

I would say that the QSM is an extension of the state machine, and QMH is an extension of the QSM.  Or, that's how I picture it in my mind's eye.

[crossrulz]

---

@billko wrote:

---

@crossrulz wrote:

---

@REAL! wrote:

Isn't a state machine with a queue a QMH?

---

Not quite.  There is a slight difference between a Queued State Machine and a Queued Message Handler.  They look alike, but the QSM handles its own queue to go through states while the QMH just accepts commands from other threads through the queue.

---

I would say that the QSM is an extension of the state machine, and QMH is an extension of the QSM.  Or, that's how I picture it in my mind's eye.

---

I would not state it quite that way.  A QSM is an extension of the Simple State Machine.  You can say this since they still act very much the same.  The QMH is in a different world.  Unlike the state machines that cycle through states in a somewhat deterministic way, a QMH just sits there and does something when it is told.  So you really can't call the QMH an extension of the state machine.  The QMH is actually an extension of the Producer/Consumer.

Nothing like arguing over semantics...

[Darren]

---

@Dennis_Knutson wrote:

...but NI will also lose points for such a question on the exam.

---

We've been doing some internal CLAD reviews...that question's days are numbered. 😉

[billko]

---

@crossrulz wrote:

---

@billko wrote:

---

@crossrulz wrote:

---

@REAL! wrote:

Isn't a state machine with a queue a QMH?

---

Not quite.  There is a slight difference between a Queued State Machine and a Queued Message Handler.  They look alike, but the QSM handles its own queue to go through states while the QMH just accepts commands from other threads through the queue.

---

I would say that the QSM is an extension of the state machine, and QMH is an extension of the QSM.  Or, that's how I picture it in my mind's eye.

---

I would not state it quite that way.  A QSM is an extension of the Simple State Machine.  You can say this since they still act very much the same.  The QMH is in a different world.  Unlike the state machines that cycle through states in a somewhat deterministic way, a QMH just sits there and does something when it is told.  So you really can't call the QMH an extension of the state machine.  The QMH is actually an extension of the Producer/Consumer.

Nothing like arguing over semantics...

---

And, semantically speaking, we're having a discussion, not an arguement.  😉

Maybe that's why I never could quite resolve why they didn't really act the same.  If I think about it, it does have a lot more in common with the producer/consumer.

[crossrulz]

---

@billko wrote:

---

@crossrulz wrote:

---

@billko wrote:

---

@crossrulz wrote:

---

@REAL! wrote:

Isn't a state machine with a queue a QMH?

---

Not quite.  There is a slight difference between a Queued State Machine and a Queued Message Handler.  They look alike, but the QSM handles its own queue to go through states while the QMH just accepts commands from other threads through the queue.

---

I would say that the QSM is an extension of the state machine, and QMH is an extension of the QSM.  Or, that's how I picture it in my mind's eye.

---

I would not state it quite that way.  A QSM is an extension of the Simple State Machine.  You can say this since they still act very much the same.  The QMH is in a different world.  Unlike the state machines that cycle through states in a somewhat deterministic way, a QMH just sits there and does something when it is told.  So you really can't call the QMH an extension of the state machine.  The QMH is actually an extension of the Producer/Consumer.

Nothing like arguing over semantics...

---

And, semantically speaking, we're having a discussion, not an arguement.  😉

Maybe that's why I never could quite resolve why they didn't really act the same.  If I think about it, it does have a lot more in common with the producer/consumer.

---

If you really want to think about it, head over to this LAVA thread.

[billko]

---

@crossrulz wrote:

---

@billko wrote:

---

@crossrulz wrote:

---

@billko wrote:

---

@crossrulz wrote:

---

@REAL! wrote:

Isn't a state machine with a queue a QMH?

---

Not quite.  There is a slight difference between a Queued State Machine and a Queued Message Handler.  They look alike, but the QSM handles its own queue to go through states while the QMH just accepts commands from other threads through the queue.

---

I would say that the QSM is an extension of the state machine, and QMH is an extension of the QSM.  Or, that's how I picture it in my mind's eye.

---

I would not state it quite that way.  A QSM is an extension of the Simple State Machine.  You can say this since they still act very much the same.  The QMH is in a different world.  Unlike the state machines that cycle through states in a somewhat deterministic way, a QMH just sits there and does something when it is told.  So you really can't call the QMH an extension of the state machine.  The QMH is actually an extension of the Producer/Consumer.

Nothing like arguing over semantics...

---

And, semantically speaking, we're having a discussion, not an arguement.  😉

Maybe that's why I never could quite resolve why they didn't really act the same.  If I think about it, it does have a lot more in common with the producer/consumer.

---

If you really want to think about it, head over to this LAVA thread.

---

Sounds fun - and educational.  What could be better?  🙂

Thanks!

[rntaboada]

In the QMH design pattern there is a similar structure to SM, but it is not the same. SM in LabVIEW is a deterministic machine, however the structure present in QMH, called Message Handling Loop (MHL) is in essence a task handler, which is not necessarily deterministic. The fact that its diagrams are handled by a queue, which can receive a message from many different places (even externally) asynchronously, makes it lose the deterministic condition. It is therefore important to understand this difference correctly. It is possible to design a "queue-driven SM"’, but without losing sight of the above, such an SM is not strictly an SM. 

But, if you decide to make a queue-driven SM, you must make sure that you have a tight control of the messages introduced in the queue so that the structure works in a deterministic way.

[aipodka1]

We were taught state machines in our Automata Theory course, but it was all theory and no practice. The existence of tools like lex yacc and bison were noted, though.

[alexderjuengere]

---

@aipodka1 wrote:

We were taught state machines in our Automata Theory course, but it was all theory and no practice. The existence of tools like lex yacc and bison were noted, though.

---

every program can be abstracted as a finite collection of states

however... do you always need to explicitly define every possible state?

- IMHO  this is  a proper usecase of statemachine (in the main.vi)

https://forums.ni.com/ni/attachments/ni/3039/11558/1/Read%20GIF%20File_LV71_V0101.zip

- this is an example of not using a state machine, which I think is the better solution in this particular case

https://github.com/dnattinger/read-xlsx-file/blob/main/source/NI%20Read%20XLSX%20File.vi

- the disadvantage of a state machine are, it can be slower  hard to read