Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!husc6!think!ames!ucbcad!ucbvax!cbosgd!cblpf!cbstr1!Karl.Kleinpaste
From: Karl.Kleinpaste@cbstr1.att.com
Newsgroups: comp.unix.wizards
Subject: Re: light weight processes and threads
Message-ID: <302@cbstr1.att.com>
Date: Wed, 15-Jul-87 22:35:50 EDT
Article-I.D.: cbstr1.302
Posted: Wed Jul 15 22:35:50 1987
Date-Received: Sat, 18-Jul-87 04:41:44 EDT
References: <8272@brl-adm.ARPA> <3872@spool.WISC.EDU>
Sender: karl@cbstr1.att.com
Lines: 64
In-reply-to: lm@cottage.UUCP's message of 13 Jul 87 20:16:35 GMT


lm@cottage writes:
> Another thing you can do is to have light weight processes.  The idea is 
> this:  run more than one process within a single process's address
> space.  Switching between these processes is little more (a white lie)
> than saving the old registers and throwing in the new ones.  All the
> other baggage is unchanged, resulting in a faster context switch.

I would disagree a bit on terminology.  The separation of a single
process' data space into multiple schedulable entities is closer to
what one thinks of as a "thread."  MACH is implementing such things,
though at times getting info on exactly what/how they're doing it is
very difficult.  One thinks of the various lines of execution through
the single space as threads, with the whole space being a process or
(as I remember the MACH terminology) a "task."  In fact, I recall a
paragraph in a MACH paper noting that a MACH task with a single thread
is effectively identical to a UNIX "process."

Lightweight processes, on the other hand, are processes whose purpose
is to carry less baggage around in an absolute sense, and are by no
means necessarily related to the separation of one space into several
lines of execution.  They have a bunch of advantages over "monolithic"
processes (such as the typical UNIX process paradigm), such as being
easy to write (a lightweight process is usually designed for a very
small, closely-defined problem, rather than trying to solve several
problems at once as one does in monolithic processes), their overhead
is smaller, and the scheduling latency is more readily controlled and
typically made much shorter.  This makes them extremely useful for
(e.g.) real-time control systems, an area where standard UNIX
mechanisms have almost always been insufficient.

Here's a short bibliography of related papers on the subject, taken
from my MS thesis which was on just this sort of topic (though my
purpose was more seriously involved in system performance improvement
aspects of lightweight processes, rather than their general structure):

Baron, Black, Bolosky, Chew, Golub, Rashid, Tevanian, and Young, "MACH
Kernel Interface Manual," CMU Dept of Computer Science, October 1986.
Try to get a more recent edition of it; thread information is (to be
kind) sketchy in the older versions.

Brooks, E.D. III, "A Multitasking Kernel for the C and FORTRAN
Programming Languages," Lawrence Livermore Laboratory, Univ of
California, September 1984.  [thread implementation inside standard C
& FORTRAN.]

Kepecs, J. and M. Solomon, "A Simplified Operating System for
Distributed Applications," 3rd PODC Conference Proceedings, 1984.
[network system with minimal kernel support (lightweight processes)
based on msg passing.]

Rovner, P., R. Levin, and J. Wick, "On Extending Modula-2 For Building
Large, Integrated Systems," DEC Systems Research Center, Jan 1985.
[thread implementation in modula-2.]

Schwan, K., T. Bihari, B.W. Weide, and G. Taulbee, "High-Performance
Operating System Primitives for Robotics and Real-Time Control
Systems," The Ohio State Univ Dept of Computer Science, July 1986,
report # OSU-CISRC-86TR1KS (to appear in ACM Transactions on Computer
Systems, 1987).

Look 'em all up, they're all interesting.

Cheers,
Karl