Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!lll-lcc!lll-tis!helios.ee.lbl.gov!pasteur!agate!saturn!edler@cmcl2.NYU.EDU
From: edler@cmcl2.NYU.EDU (Jan Edler)
Newsgroups: comp.os.research
Subject: Re: THREADS, Light weight processes
Message-ID: <5467@saturn.ucsc.edu>
Date: 15 Nov 88 04:13:50 GMT
Sender: usenet@saturn.ucsc.edu
Organization: New York University, Ultracomputer project
Lines: 71
Approved: comp-os-research@jupiter.ucsc.edu


This topic is a few weeks old, but a mail/news problem here delayed my
followup.  I agree in general with most that has been said on this topic,
mostly that there are many different things going around under the same
or similar names, such as "threads" and "lightweight processes".  Which one
you want depends on your needs, goals, and environment.  There are a couple
of other comments I would like to make as well.

First, I want to respond to one opinion expressed by mcvax!jack (Jack Jansen)
in article <5354@saturn.ucsc.edu>:
> So far nobody seems to have mentioned that LWPs are a very nice
> mechanism to program with, much nicer than non-blocking I/O with
> completion interrupts or polling, etc.

> Just look at your average unix utility that uses SIGURG or select()
> and imagine what it would look like when written as a set of
> cooperating LWPs using blocking primitives and you'll get the
> point.....

This was also agreed to by libes@cme.nbs.gov (Don Libes) in article
<5394@saturn.ucsc.edu>:
> I agree completely.  I recently wrote an article discussing exactly
> this.  It showed the difficulty of writing a conceptually simple
> program, and how it resolved cleanly into 3 threads, just a couple of
> lines a piece.  It also discussed threads with respect to OS/2 and UNIX.

Anyway, I have to say I disagree.  There are two issues here, syntactic
and conceptual.

Things like constructing control blocks, checking for error conditions,
etc., can be a real hassle in asynchronous I/O systems, but LWP systems
can have just as much crap to deal with (e.g. stack space allocation,
etc.).  It just depends on how low-level the programmers' interface is,
and how fancy the facility is.  There is no reason not to provide an
easy-to-use asynchronous I/O interface.

Conceptually, both asynchronous I/O systems and LWP systems are sources
of complexity.  Both require you to deal with language/compiler issues
having to do with asynchronous access to shared variables (at least
something like volatile in ansi c, and possibly much more.  Or a dumb
compiler).  Race conditions can arise in either kind of system, and can
be equally hard to debug.  But a LWP mechanism is fundamentally more
powerful; basically I'm talking about the difference between interrupts
on the one hand, and MIMD shared memory multiprocessing on the other.
Clearly interrupts are not as powerful as multiprocessing, but their
inherent structure and relative simplicity can make them somewhat more
appropriate when that full power isn't needed.  Of course, there may be
other reasons why you want multiprocessing anyway; that's fine too.

The other point I would like to address is whether kernel support is
needed for LWPs.  There are a couple of reasons usually given for why
kernel support is needed: you don't want a HWP suspended when a LWP
(running "on" that HWP) does I/O, or incurrs a page fault.  Both these
problems can be addressed with interrupts (signals), as an alternative
to kernel-supported LWPs.  The use of asynchronous I/O in the
implementation of the user-level LWP system is fairly straightforward:
since the I/O is asynchronous, the HWP doesn't block, but can switch to
a new LWP.  Page faults can be handled similar to the way real
operating systems handle them: generate an interrupt to a piece of
memory-resident code that deals with the situation.  In this case and
all that is necessary is to switch to a new LWP.  When the page fault
has been satisfied, another interrupt (analogous to the I/O completion
interrupt generated by the hardware when the page-in is done) can cause
the blocked LWP to be made ready again.  Of course, there may be other
reasons for choosing kernel-supported LWPs, but I don't think I/O and
page fault handling are good arguments in favor of doing it that way.

Jan Edler
NYU Ultracomputer Project
edler@nyu.edu
cmcl2!edler