Re: [9fans] cooperative threads

Re: [9fans] cooperative threads

[rob pike]

> I think threads are popular for two main reasons:
> (1) They are an easy way to exploit multiple processing units.
> (2) They are much lighter weight than communicating full processes.

1) is irrelevant on a uniprocessor while 2) is a red herring: processes
are not intrinsically heavyweight.  Nonetheless, I agree that these
are the reasons threads are popular.

However, they are used throughout Plan 9 for a different reason:
they provide an excellent approach for structuring programs,
especially programs that must handle multiple sources of input.
Examples include user-level file servers and anything interactive.
See
	http://plan9.bell-labs.com/cm/cs/doc/89/1-a.ps.gz
for some old thinking of mine on the subject.  This paper was
written a couple of years before 8½, but you can see where I'm
going.

-rob

Re: [9fans] cooperative threads

[Douglas A. Gwyn]

Lucio De Re wrote:
> It is quite amusing to recollect Edsger Dijkstra's horror when asked
> to program a very early pre-emptive computer.  He is reported to have
> needed serious convincing before he accepted the principle of
> _interrupts_ :-)

With good reason.  In the early days, before people like Dijkstra
and Hoare had developed reasonable models for concurrency, it was
hard to control the concurrency in preemptive (interrupt)
environments.  For example, the CDC 1700 operating system had
several forms of I/O, the one necessary for double-buffering
involving a "completion routine" that would be invoked when the
I/O request had been satisfied.  It was possible to write correct
applications under such a scheme, but it was much easier to write
ones with race conditions etc.

I think threads are popular for two main reasons:
(1) They are an easy way to exploit multiple processing units.
(2) They are much lighter weight than communicating full processes.

Re: [9fans] cooperative threads

[Lucio De Re]

On Fri, Aug 18, 2000 at 06:06:14PM -0400, Russ Cox wrote:
> 
> 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.
> 
Are you sure programs aren't _meant_ to be bug free?

It is quite amusing to recollect Edsger Dijkstra's horror when asked
to program a very early pre-emptive computer.  He is reported to have
needed serious convincing before he accepted the principle of
_interrupts_ :-)

Russ is bothered by the connection one makes immediately between
threads and performance, and I agree with him.  What bothers me,
however, is the acceptance today, no doubt engendered by the need to
harness computing power on a scale unthinkable only a generation ago
(I wonder if there might in fact be one or more generation gaps in
there), that programming is an imprecise art form.

Despite failures to "prove" the correctness of programs, it is
possible to write bug free code.  Unfortunately, it no longer seems
necessary or desirable to do this.

I used to compare computers to automobiles to get that cozy feeling
that I was in a more rational environment, working to much better
defined parameters.  Not long ago General Motors compared Microsoft
Windows to their vehicles to illustrate the exact opposite.

Sigh!  I guess I'd better get off my soapbox now.

++L

Re: [9fans] cooperative threads

[Boyd Roberts]

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

not only that.  windows is event driven and i have
a zillion example where WinSock messages arrive
_out of order_.

ie. you can get write-true _before_ connect.

btw: i'm only admitting this through unfortunate
     knowledge that i've gained from 2 years of
     2 years of windows 3/95/NT coding -- and they
     told me it was gonna be a 'unix tcp/ip'
     contract.  i needed a job, in paris, so i
     said ok.

     anyway, given the ghastly environment, it's _very_
     hard to write a (bug free) windows program.

[9fans] cooperative threads

[Russ Cox]

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