Re: Pushing Hot Buttons - Object State Machines === Threads with goto's

Responding to Carter...

<Hot Button>
A pet peeve of mine is the resistence one gets from IT people to using
object state machines routinely. The fact is that with interoperability,
networking, multi-tasking, distributed processing, mutli-user systems,
etc., etc. IT is no longer one's grandfather's IT. It is much more like
R-T/E. However, to avoid thinking about asynchronous processing, the
industry is making major investments in layered model infrastructures that
serialize asynchronous processing so CRUD/USER developers can think
serially. The cost of that is outrageous overhead. Then people wonder
why they need to upgrade their desktop to the equivalent of a 1984
mainframe just to run a spread*** that ran fine on a TRS-80 in 1984.
</Hot Button>


At risk of appearing trollish, I'm going to push that Hot Button.

Ah well, no. I am trolling, (just in pure friendly fun), but I will say in
my defence that the content of what I'm about to say is mathematically
absolute correct, sometimes even useful and may give people pause to think.

Mathematically speaking every program with a state machine is equivalent
to and may be replaced by another containing an extra thread and no
state machine. (Conversely every program containing a thread may be
replaced by one contain one less thread an a state machine)

Asynchronous processing is not the same as concurrent processing. While concurrent processing almost always involves asynchronous processing, it is rather common to have asynchronous processing without concurrency (i.e., a single event queue that waits until the current event is fully consumed before popping the next).

State machines are the most natural way of dealing with asynchronous processing. Threads are the most natural way of dealing with concurrency (even in a multi-processor environment because the 3GLs still use synchronous procedural message passing).

You are correct that there is a rigorous mapping between asynchronous FSM solutions and threaded concurrent solutions. But that is pretty much why one uses an asynchronous model in the OOA/D -- to be confident that the solution can be mapped into a concurrent implementation environment if nonfunctional requirements demand it. Corollary: it is much easier to do the asynchronous solution first and map it into a concurrent implementation than it is to jump directly to the concurrent solution.

[FYI, there is a sort of Poor Man's concurrency that one can have using state machines without threading. One can employ multiple event queues and allocate different object state machines (or groups of object state machines) to each queue. Then one can time slice at the action level by simply doing a round robin of the event queues. The next step is to prioritize the queues with semaphores. This gives one the same concurrency that threads do under the hood in a single processor environment. The advantage is that there is a lot less overhead because the OS thread services need to be able to time slice at the instruction level; swapping at the action level just reuses the existing <procedural> context switching mechanisms. (Caveat: there are some circumstances where this will not work, but those contexts can give thread design trouble too.)]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Quantcast