Path: utzoo!utgpu!watmath!clyde!mcdchg!chinet!att!ulysses!thumper!faline!bellcore!rutgers!mailrus!ames!pasteur!agate!saturn!riedl@purdue.edu
From: riedl@purdue.edu (John T Riedl)
Newsgroups: comp.os.research
Subject: Re: THREADS, Light weight processes
Message-ID: <5292@saturn.ucsc.edu>
Date: 28 Oct 88 13:44:33 GMT
Sender: usenet@saturn.ucsc.edu
Organization: Department of Computer Science, Purdue University
Lines: 88
Approved: comp-os-research@jupiter.ucsc.edu


'Thread' is another (shorter!) name for a lightweight process.
Threads improve efficiency on many architectures by recognizing the
distinction between address space operations and thread-of-control
operations.  The efficiency of three basic operations is improved:
creation, deletion, and context switch.

Address space creation/deletion is expensive, since a significant
amount of state is preserved for each address space.  Secondary
storage access may be required on swapping or paging systems.  Thread
creation and deletion is cheap.  A new entry is added to the thread
table in the address space in which the thread will run.  Basically,
the state information in this entry is a copy of the contents of the
processor registers for the thread.  Removing such an entry is even
simpler.

Address space context switch may be expensive, especially on virtual
memory machines.  Processor caches must be flushed, a process may have
to be swapped from secondary storage, etc.  Thread context switch
within an address space is trivial.  The processor simply saves a copy
of its registers in the thread table, and loads a new copy.  In many
ways thread context switch is more like a procedure call than an
ordinary context switch.  Note that to take advantage of these more
efficient context switches, systems that use threads must have a
two-level scheduling algorithm that minimizes switches between address
spaces.

In article  <5287@saturn.ucsc.edu> mudd-j@bear.cis.ohio-state.edu (John R. Mudd) writes:
>
>In article <5279@saturn.ucsc.edu> rutgers!mist.math.uoregon.edu!renga@beaver.cs.washington.edu (Renganathan Sundararajan) writes:
>
>>    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? 
>
>Speed.  See above.  

I think this is a misunderstanding.  Threads must save the PC,
condition flags, *and general registers*.  The speed comes from
avoiding avoiding the checkpointing of address space data (page
tables, etc.).

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

The V System from Stanford uses threads.  I think their nomenclature
is 'task' for address space and 'process' for thread.

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

What sort of hardware support is needed?  Most architectures already
provide instructions for efficiently saving processor state to improve
procedure call performance.  Some machines (like Suns) provide
hardware support for address space context switching, in the form of
multiple hardware address space contexts.  This is the reason for the
performance 'knee' on Suns when more than a certain number of contexts
are in the run queue (7 on a 3/50; 15 on a Sun 4, I think).  In one
way threads help avoid this knee, since a group of related
asynchronous activities can be organized as a single address space.

Here are references to Mach and V, both of which have threads:

@Article{mach-overview,
	Author = "Richard F. Rashid",
	Title  = "Threads of a New System",
	Journal= "Unix Review",
	Number = 8,
	Volume = 4,
	Month  = aug,
	Year   = 1986,
	Pages  = "37--49"
}

@Article{V-process-groups,
	Author = "David. R. Cheriton and W. Zwaenepoel",
	Title  = "Distributed Process Groups in the {V} Kernel",
	Journal= TOCS,
	Volume = 3,
	Number = 2,
	Month  = may, 
	Year   = 1985,
	Pages  = "77--107"
}

John
-- 
John Riedl
{ucbvax,decvax,hplabs}!purdue!riedl  -or-  riedl@cs.purdue.edu