Queued State Machine, not a state machine?

[Miles Young]

I've been reading up a bit on design patterns that seem popular among LabVIEW users, and I have a question with regards to the design pattern described in the following article:

http://expressionflow.com/2007/10/01/labview-queued-state-machine-architecture/

I don't see how this is a state machine at all. To me it just looks like a producer/consumer pattern for queuing up actions (what is described in the article as states) to be executed in the consumer loop. I don't see where a state machine comes into play, determining state transitions based on current state and inputs, like shown in the following:

http://zone.ni.com/devzone/cda/tut/p/id/3024

Am I completely off?

[Spectre_Dave]

That Design Pattern is really a Queued Message Handler.

[Miles Young]

Yeah exactly.

I was thinking a nice way to implement something QSM-like would be to produce instances of a message handler object that maintains its own state and a message queue. You could produce a new object for network I/O that inherits from the general message handler, one for managing the UI, data aquisition etc. They would communicate in a network by passing messages back and forth to their respective queues and each would be a true implementation of a state machine.

Has to be right up LabVIEW's visual alley 🙂

Edit:

Now that I come to think of it, this would be almost exactly what could be done compactly with LabVIEW event handlers and user-generated events.