Path: utzoo!utgpu!watmath!clyde!mcdchg!chinet!att!ulysses!thumper!faline!bellcore!rutgers!mailrus!ames!pasteur!agate!saturn!karl@triceratops.cis.ohio-state.edu
From: karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
Newsgroups: comp.os.research
Subject: Re: THREADS, Light weight processes
Message-ID: <5295@saturn.ucsc.edu>
Date: 28 Oct 88 20:10:24 GMT
Sender: usenet@saturn.ucsc.edu
Lines: 132
Approved: comp-os-research@jupiter.ucsc.edu


mudd-j@bear.cis.ohio-state.edu (John R. Mudd) writes:
   > What exactly is a light weight process?
   > Is it the same as a thread?

   A lightweight process, sometimes called task (Encore's UMAX) or
   a thread (Mach), is a smaller thread of execution that doesn't have
   all the capabilities of a UNIX process, and as such it is cheaper
   to create and has less overhead associated to it.  As UNIX
   processes are scheduled on a machine's processor(s), so are tasks
   scheduled on a program's available UNIX processes.  A parallel
   program creates a number of UNIX processes on which the program's
   tasks can be created.

Don't get caught in the trap of considering LWPs only in the context
of UNIX.  There are a number of implementations of LWP concepts in
other OSes, some of them not at all UNIX-like.

   > Where did the notion of a LWP originate and in what context?

   To do efficient (in terms of the OS) parallel processing, it isn't
   a wise idea to create a lot of UNIX processes.  UNIX processes tend
   to have a lot of 'stuff' in them that isn't necessary for parallel
   processing.

They're also useful for other things, e.g., fast, efficient
communication among a set of cooperating processes where the processes
aren't necessarily `parallel' in nature.

   > Is the sole purpose of a LWP to help switch contexts fast?

There's lots of potential uses for them.  LWPs generally don't carry
the heavy baggage around with them that a normal ("heavy") process
does.  For example, it may not claim a distinct data space of its own,
it may borrow a register set from a common parent (typically a HWP
parent), it may have a reduced concept of a process control block
requiring less intervention and mangement by the kernel on its behalf,
that sort of thing.  That's why they're "light."

Insofar as their use for speedy, low-overhead operations goes, a lot
of certain kernel's internals are not well-tuned for LWP usage.  I had
problems with the foolishness of UNIX' wakeup() wanting to search the
whole proc[] table - that cost me CPU time in a big way.

   > If a LWP does not own/use any registers and so saving a context
   > involves only saving the PC and condition flags, what is great
   > about it?

I would say it's the combination of minimal resource usage, in
relation to how it affects speed, as John suggested.  My grad work was
done in LWPs which were compiled as part of a SysV kernel, hence
claimed no data space of their own, and could be switched into context
instantly without ever having to worry about such delaying problems as
swapping and the like.

   > Do LWPs and HWPs (H = Heavy - whatever that may mean) co-exist in an OS?

   LWPs exist in a HWP, which are then scheduled by the OS.  See above.

Oops, don't overstate the case, John.  LWPs can exist independent of
any other processes.  Mine did - they were an extra process-context
level of interrupt processing.  LWPs tend to be used for very
specialized functions (mine were deeply concerned with tty I/O),
whereas typical processes tend to be intended for a whole bunch of
things, which results in heavier usage of comparatively expensive
resources like memory or peripheral I/O.

My LWPs were spawned at boot time by the kernel just after creation of
init, and they then sat waiting for tty events.  They were not
attached to any other process in any way.  They did not interfere with
normal HWPs in any way.

   > Is the notion of a thread unique to MACH or do other os like V use it?

Not at all unique to MACH.  Take, for example, Kepecs & Solomon's
message passing kernel (see ref below).

   > Are there any machines out there that provide some kind of hardware
   > support to LWP switching?

I couldn't say.  I'm not aware of any.

   > Any clarifications/references would be appreciated.

Some of these are closely relevant, some are not.  This is from the
bibliography to my MS thesis, not quite two years old.

Abu-Sufah, W., H.E. Husmann, and D.J. Kuck, ``On Input/Output Speedup
in Tightly Coupled Multiprocessors,'' IEEE Transactions on Computers,
June 1986, Volume C-35, pp. 520-30.

Baron, R.V., D. Black, W. Bolosky, J. Chew, D.B. Golub, R. Rashid, A.
Tevanian, Jr., and M.W. Young, ``MACH Kernel Interface Manual,''
Carnegie-Mellon University Department of Computer Science, October
1986.

Black, A.P., ``Supporting Distributed Applications: Experience with
Eden,'' Proceedings of the Tenth ACM Symposium on Operating System
Principles, December 1985.

Brooks, E.D. III, ``A Multitasking Kernel for the C and FORTRAN
Programming Languages,'' Lawrence Livermore Laboratory, University of
California, September 1984.

Clark, D.D.  ``The Structuring of Systems Using UpCalls,'' Proceedings
of the Tenth ACM Symposium on Operating System Principles, December
1985, pp. 171-80.

Jones, M.B., R.F. Rashid, and M.R. Thompson, ``Matchmaker: An
Interface Specification Language for Distributed Processing,''
Proceedings of the 12th Annual Symposium on Principles of Programming
Languages, January 1985, pp. 225-35.

Kameda, H., ``Effects of Job Loading Policies for Multiprogramming
Systems in Processing a Job Stream,'' ACM Transactions on Computer
Systems, Volume 4, February 1986, pp. 71-106.

Kepecs, J. and M. Solomon, ``A Simplified Operating System for
Distributed Applications,'' 3rd PODC Conference Proceedings, 1984.

Rovner, P., R. Levin, and J. Wick, ``On Extending Modula-2 For
Building Large, Integrated Systems,'' DEC Systems Research Center,
January 1985 pp. 16-20.

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 University Department of Computer and
Information Science, July 1986, report number OSU-CISRC-86TR1KS (to
appear in ACM Transactions on Computer Systems, 1987).

Have a blast,
--Karl