On Thu, 11 Sep 2008, Douglas Royds wrote:
John Carter wrote:
"State Machines" are the embedded development flavour of the month?
year? (god forbid) decade? but are nothing more than multi-threaded
tangle of computed goto's with a roll your own scheduler in drag. :-))
(Oh dear... I have probably offended about half my colleagues. :-))
So I better add some fine print... "but can be useful in strict
latency requirement systems having insufficient RAM to create a stack
for each thread / State Machine."
Can't let that one go uncommented:
State machine != Multi-threading
State machine != Scheduler
Independent concepts. One can be used without the other.
Ah... but putting on my mathematician hat for awhile.... you can
fairly mechanistically transform any program with N state machines
into a program with N threads, no state machines and no
gotos.
(Mathematicians fineprint... There is no mechanistic way of
transforming every way of specifying a state machine, there are too
many ways of specifying / implementing a state machine. However, give
me any single precise way of specifying / implementing a state
machines, I can show you how to mechanistically transform every state
machine specified in that manner.)
Whilst a state machine != a scheduler... the code allowing more than
one state machine to coexist in one thread / process is a crude roll
your own, single purpose throw away scheduler.
As such it is grossly simpler than a general purpose scheduler. So
much so that you have failed to observe that it _is_ a scheduler. It,
as does any scheduler, determine the sequence of execution of the
state machine event handlers.
Which is Best? Personally I prefer the N process (not thread) / no
state machine / structure programming / communicate only via event
queues architecture.
But I quite understand that there are constraints like a device has no
MMU, a device has insufficient ram for N stacks, ... which may dominate
over my desire for robustness, generality, scalability and maintainability.
Anyhoo, galloping off along the processes vs threads vs state machines
tangent... I recently felt quite vindicated....
Way back round about Windows 3.1 Microsoft windows had really lousy
heavy weight processes. They had failed to understand fork / mmap and
hence had reimplemented Unix poorly.
Instead of implementing it correctly, they cranked up their
marketing department instead...
So for a couple of years you couldn't turn around at a trade show
without being prodded in a hundred directions with the Microsoft
mantra that Processes are Too Heavy, Threads are the Wave of the
future.
I kept saying to anyone who'd listen... Threads are Bad, Unix
processes are way better for a longish list of reasons.
Needless to say, a couple of million dollars of marketing muscle won
the day...
However, technical truth eventually wins out...
http://developers.slashdot.org/article.pl?sid=08/09/10/196224
Oh.. and if you want the longish list of reasons... Google have even
listed some of them in convenient webcomic form! (Irritatingly presented as if
they had just thought of Something Clever, instead of reverting to
what was well known literally decades ago!)
http://blogoscoped.com/google-chrome/4
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : [EMAIL PROTECTED]
New Zealand
