[Baypiggies] asynch design
K. Richard Pixley
rich at noir.com
Mon Feb 8 18:04:54 CET 2010
My initial experience with either paradigm was coop, (ie, no preemptive
scheduling). The entire original macos was cooperative event based.
Most windows/icon/mice interfaces, (including X11), were originally
event based. And the ISIS toolkit, (an early version of what is now
called "virtual synchrony"), was a messaging system without a "read"
call. Instead, incoming messages spawned a "thread", (really
implemented as a coop event based tasking system).
Also, my first asynchronous parallel system was back in the 80's with
Sequent Balances and later Symmetries combined with Sun 3/50's. There
were no widely available threading systems then although the coop
threading systems were beginning to show up in various places. I
designed and built an entire multiple machine, asynchronous ticker plant
using heavy weight unix processes, sysv unix IPC, sockets, and hardware
atomic locks. (And later replaced it with an ISIS based system).
Early implementations of threads were cooperative and many were
implemented using event based systems. That is, threads which blocked
blocked the entire heavy weight process. At that point, the distinction
between threads and an event based system was largely moot. If you
wanted an asynchronous system, then you had to think about blocking and
potential task switching with each and every call either way.
Granted, modern threading systems are preemptive and much more heavy
weight than the earlier systems. Threads have lost much of their
efficiency in favor of a simplified user paradigm, (aside from
debugging), which now virtually mimics the original unix process
paradigm, (complete with shared memory, forks, multiple asynchronous
processes, atomic hardware locking, etc). Personally, I'd prefer to use
the unix facilities at that point because they are more efficient and
easier to debug. From that perspective, threads offer very little in
the way of functionality or efficiency over prior, well known alternatives.
I agree that if you haven't used any of these paradigms, then threads
might be a simpler paradigm to learn initially, if you assume that your
threading system is part of your operating system or you assume that all
threading systems are preemptive and therefor comparable. Event based
systems force the developer to confront the task switching mechanism and
to sort through starvation scenarios. If you're going to sort through
those scenarios anyway, or if you're going to need to examine your
switching mechanism closely, then I argue that event based systems are
simpler to understand in total than thread based.
So I suppose I agree that if you only need to understand a portion of
the problem space, then threads are probably easier, (so long as you
don't need to debug anything).
More information about the Baypiggies