Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!agate!saturn!steve@basser.oz
From: steve@basser.oz (Stephen Russell)
Newsgroups: comp.os.research
Subject: Re: THREADS, Light weight processes
Message-ID: <5330@saturn.ucsc.edu>
Date: 31 Oct 88 01:07:19 GMT
Article-I.D.: saturn.5330
Sender: usenet@saturn.ucsc.edu
Organization: Dept of Comp Sci, Uni of Sydney, Australia
Lines: 65
Approved: comp-os-research@jupiter.ucsc.edu

In article <5279@saturn.ucsc.edu> rutgers!mist.math.uoregon.edu!renga@beaver.cs.washington.edu (Renganathan Sundararajan) writes:
>
>  I came across the notion of  multiple THREADS of control executing 
>  within a single address space [...]
>  Questions:
>
>    What exactly is a light weight process? 

In general, threads == LWPs.

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

Earliest ref I have is Cheriton's Thoth, which had multiple processes
executing in same address space (a team). There were probably earlier examples.

>    Is the sole purpose of a LWP to help switch contexts fast? 
>    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? (if a process never uses any registers just so 
>     that context-switches can be done fast, is there any advantage
>     at all? Am I missing something here?)

Context switches involve more than just registers. Consider cost of switching
address spaces, which may involve changing many segment/page address registers.
Switching between LWP's in the same space saves this cost. On systems which use
virtual caching (eg, 68020), it is usually necessary to flush the I & D caches
after a full context switch. Again, this is unnecessary if switching between
LWP's in the same space.

There are other advantages, though. Firstly, LWP's usually share data, unlike
most UNIX processes. The cost of creating a LWP is much lower, because no
memory allocation need be done - this can be made particularly cheap if the
creator provides the storage for the child processes stack. So, a LWP can
be created as fast as you can grab a free entry from the proc table, and
set up the PC and SP for the new proc.

Also, LWPs are a useful way of structuring the OS kernel. For example,
the Thoth kernel consisted of a group of LWPs, each managing some
resource. For further details, see Cheriton's book "The Thoth System:
Multi-process Structuring and Portability", Elsevier, 1982.

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

Yep. LWP's execute within the address space of a HWP (a Thoth "team"). A HWP
is considered a single unit from the point of view of swapping/paging, memory
allocation, etc, and may also be the place that info about open files, etc,
is kept (assuming LWPs share files). You create new HWPs whenever you need
a new address space; eg, to execute a new program.

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

Nope. Thoth and its derivatives (Port, Hermes, V) have them. In fact, most
modern OS's do (ie, those that aren't just UNIX clones :-).

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

Not really needed, as LWP switching involves _just_ switching the registers.
We can even make this cheaper by refusing to preserve registers across system
calls, so that all we need to save is the PC/SP (and possibly a FP). Of course,
if a process is suspended as a result of an interrupt, we must save all its
registers, and restore them later during the interrupt return sequence. However,
voluntary suspensions (eg I/O requests) cost very little.

LWPs are a nice way of structuring systems, not just for parallel programming,
but OS's in general. See Cheriton's stuff - it is very good.