Event Programming – Relationship Between Event-Driven Design and State Machines

The hidden transitions and the latency make this a pretty interesting problem, especially since you can't modify the gadget. You may be looking for a synchronizing sequence or a homing sequence. ("Synchronization" means you can issue some sequence of commands, and be sure of the state of the target state machine when you're done. "Homing" means that you can issue some sequence of commands, then verify the state by examining the output of the state machine).

Sven Sandberg has a pretty good paper showing that (for any well-defined Mealy machine) you can always construct these two types of sequences. It's all theory, no code, so you'll have to do some implementation. Here's the citeseer reference to the paper itself, and a PDF slideshow of the ideas.

In the case you describe, latency is still an issue. I'm curious to know if you have some idea of the margin of error on these "hidden" state changes. How long between them? Are they more common, or more frequent, in some cases than others? Answers to these questions can help you define these control sequences.

I've found that processing events using a stack of internal events (more specifically, a LIFO queue with arbitrary removal) greatly simplifies event-driven programming. It allows you to split the processing of an "external event" into several smaller "internal events", with well-defined state in between. For more information, see my answer to this question.

Here I present a simple example which is solved by this pattern.

Suppose you are using object A to perform some service, and you give it a callback to inform you when it's done. However, A is such that after calling your callback, it may need to do some more work. A hazard arises when, within that callback, you decide that you don't need A any more, and you destroy it some way or another. But you're being called from A - if A, after your callback returns, cannot safely figure out that it was destroyed, a crash could result when it attempts to perform the remaining work.

NOTE: It's true that you could do the "destruction" in some other way, like decrementing a refcount, but that just leads to intermediate states, and extra code and bugs from handling these; better for A to just stop working entirely after you don't need it anymore other than continue in some intermediate state.

In my pattern, A would simply schedule the further work it needs to do by pushing an internal event (job) into the event loop's LIFO queue, then proceed to call the callback, and return to event loop immediately. This piece of code it no longer a hazard, since A just returns. Now, if the callback doesn't destroy A, the pushed job will eventually be executed by the event loop to do its extra work (after the callback is done, and all its pushed jobs, recursively). On the other hand, if the callback does destroy A, A's destructor or deinit function can remove the pushed job from the event stack, implicitly preventing execution of the pushed job.