[9fans] cooperative threads

["Russ Cox" <rsc@plan9.bell-labs.com>]

A more important point is that coroutines,
or cooperative or non-preemptive threads,
or whatever you want to call them, have their
benefits.

As demonstrated by early versions of Windows
and the Macintosh OS, reliance on cooperative
threading alone is a recipe for disaster, since 
it requires that all threads be bug free.  Thus,
used as an OS's primary scheduling mechanism,
cooperative threading requires that all executing
programs be bug free, a very strong and very
unlikely condition.  In that arena, cooperative
threading is not the right framework.

In more controlled settings, cooperative 
threading can work well.  If you arrange things
so that the only accesses to a data structure
are from threads inside a single proc, you
don't need to lock the data structure as long
you don't do a potentally blocking operation
(like communication) while manipulating it.
This is just one small benefit.  Structuring 
using coroutines can simplify other aspects
as well.  See, for instance, the ``Concurrency
in the Implementation'' section of the Acme
paper, any of the three references listed in
that section, and www.cs.dartmouth.edu/~doug/squint.ps.gz.

One of my gripes about the software-writing
world is that too many people hear threads
and think of performance alone.  A friend of
mine was taking a networks class and was
barred from using threads to simplify his
program structure.  The justification given
was that on the OS in question the thread 
package did not involve the kernel, so there
were no performance wins to be gained.
Thus using threads had no point.

My intent is not to get into an argument over what
the ``right'' scheduling model is, since it depends
greatly on the task at hand.  Instead I simply
wish to point out that cooperative threads do
have their uses and merit a place as a single tool
in a larger toolbox.

Russ