[Arch] Which code style is more robust and why?

[drjdpowell]

---

@Intaris wrote:

At the beginning of each iteration, I first check if the private Queue has elements in it and I finish them before taking the next item off the public.  Both queues are of identical datatype. 

---

It's long been my opinion that any "QSM" (really, a QMH) should be of this kind of design, where any "from outside" action is completed before starting handling of the next.  The JKI State Machine does satisfy this, but many other designs don't, including the templates put out by NI.  I recently gave a talk on this very subject at a CLD Summit in Newbury, UK.

[xChiron]

Actually, i'm not a fan of medium-large state machines (even the Hierarchical ones, where exists the relationship between SuperState and several substates, creating a kind of inheritance) because, i believe (at least) the code reuse is more related to share functionality (SubVI's)  instead of share semantics (State reuse).

Anyway, lot of insighful answers. Kudos to everyone 🙂

[drjdpowell]

---

@xChiron wrote:

Actually, i'm not a fan of medium-large state machines

---

Just a note for anyone reading; the structure such as in the OP, which are often called "Queued State Machines", are actually not "State Machines" at all.  They are Queued Message/Event Handlers.  They queue up actions, not state (you can't queue up state).

[BowenM]

Just my two cents...

One of my favorite architectures is using a state machine with a queue interrupt.  Each loop iteration it checks the queue looking if something needs to be dequeued.  If it does, the queue state supersedes the current state - if not the state machine continues as normal.

[RavensFan]

Any reason not to just use a Dequeue element with a zero timeout value?  If the Dequeue time out, then you know the queue was empty.

[BowenM]

---

@RavensFan wrote:

Any reason not to just use a Dequeue element with a zero timeout value?  If the Dequeue time out, then you know the queue was empty.

---

I originally used it in a control loop where timing was critical, and have since just copied the code.  Dequeue is about an order of magnitude slower than obtain queue status.  Both are very fast and it likely didn't make a difference, but....

[RavensFan]

Very interesting.  I wouldn't have expected that.

[Intaris]

You need to wire the output of the queue status. It may be optimised away otherwise.

[RavensFan]

I thought of that too.  So I added indicators on the Timeout terminal of the Dequeue, and the #pending remove terminal on the status.  Results were very similar both in actual value and ratio between the two examples.

If there is anything else missing in the benchmarking example, I can't find it.

[Intaris]

Yup, just got the same results here.  Go figure.  That's news for me and it's a big enough difference to definitely remember for the future.