http://www.scriptics.com/people/john.ousterhout/threads.ppt
I discovered that John Ousterhout left Sun last month to work
at Scriptics, a company dedicated to building scripting tools
and languages. For those of you who don't know him, it goes
Wall : Perl :: Ousterhout : TclTk
For the record, I had first met John at that W3C/OMG workshop on
distributed objects and mobile code that everyone seemed to be at in
June 1996 in Boston. His paper:
http://www.scriptics.com/people/john.ousterhout/mobile96.html
My paper by comparison was awful, but hey, it got me out there to meet
him and Guido van Rossum and Dan Connolly and Rich Soley and several
others for the first time, so it was worth it
http://www.infospheres.caltech.edu/papers/domc96.html
They just don't make W3C/OMG workshops like that any more. The
Compositional Software Architecture workshop in Monterey in January 1998
paled in comparison even though our position paper was much better
http://www.cs.caltech.edu/~adam/papers/csa98b.html
Anyway, all of John's recent papers have migrated with him to
http://www.scriptics.com/people/john.ousterhout/
It was Ousterhout's paper with the threads.ppt slides -- an invited talk
at the 1996 USENIX technical conference -- that shifted my mind out of
its parallel programming mode two years ago in search of the simpler,
less-likely-to-be-errorprone event-oriented paradigm that I've since
been doing my thesis work on.
Rereading his slides I can recall the rational arguments he made against
thread synchronizations, which burden the programmer with dealing with
deadlocks and livelocks and preemptions and race conditions and subtle
causality errors. Furthermore, debugging threads is painful. Threads
should only be used when true CPU concurrency is required, as they are a
general-purpose mechanism for managing concurrency; however, with event
loops, an independent (short-lived) event handler can be invoked
explicitly in a new thread for each incoming event, so the concurrency,
though somewhat limited, comes free from thought of deadlocks and
synchronization errors.
The main problem is sharing state across event handlers: then you have
to introduce locks, bringing in all the baggage associated with them.
But my intuition is that we can unify the API for event models at
different levels of the application stack -- from GUIs to OS events to
events between components of a document to events traveling across the
Internet -- and in so doing garner the same kind of win with regard to
adaptability that events in Ousterhout's talk had over threads.
More on this in my next post...
----
adam@cs.caltech.edu
Your judgment is a little off at this time.
-- Rohit's fortune cookie last night at 4:19am