[Baypiggies] asynch design

[K. Richard Pixley]

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).

--rich