mok@cs.utexas.edu (Al Mok) (08/02/89)
I think of the introduction of light-weight processes as a means to
alleviate a (not very well recognized) fundamental weakness in traditional
operating systems.
In order to transform an application concept into operational software,
the computational requirements of the application must at some point be
mapped into a set of processes (as in a Unix process). The crux of the
problem is that, in relation to this mapping, the process is the same
architectural unit that is used to serve at least three different
purposes which might conflict with one another. Specifically, the
process serves as a unit for:
(1) Resource allocation, e.g., the scheduling unit for the cpu.
(2) Integrity management, e.g., Hoare's concept of a monitor.
(3) Task (job) elucidation, e.g., define the job that is created to monitor an
airplane that has just entered the air traffic controller's sector.
These three different roles of the process may require the computational
requirements of an application to be broken up in different granularities
and thereby impose an unnecessarily difficult tradeoff. This difficulty
is manifested whenever the requirements for two or more of (1), (2) and (3)
are acute, as are likely in time-critical applications. For some examples,
the interested reader might want to read an article I wrote for the
Proceedings, International Workshop on the Software Process and Software
Environments, March 27-29, March 1985, Coto de Caza, California. This
proceedings also appeared as a special issue of ACM SIGSOFT Software
Engineering Notes, vol. 11, no. 4, August 1986. My article "The Von Neumann
Straitjacket - the Process Construct" appears on pp. 60-63.
In this context, the light-weight process is an engineering solution
for separating the need for efficient resource allocation from other concerns.
(By a light-weight process, I mean a "thread" or a "locus of control",
i.e., program counter + other control information. I view a register set
as an instance of a subset of an address space and as such is not an essential
part of a light-weight process.)
Rather than retrofitting traditional operating systems with piecemeal
patches, it'd be interesting to reconsider the design of operating systems
by providing independent architectural units for resource allocation,
integrity management and task (job) elucidation etc. For example, an address
space could be a first-class object that may be attached to the context
"socket" of a thread. Such ideas and their many variations have indeed
been around for a while, e.g., see Jon Sieber's MS thesis "TRIX: a
Communication Oriented Operating System", MIT EECS MS Thesis, 1984.
The L-machine project at MIT (Steve Ward) should be of interest too.
I don't think, however, there is any concensus on what the basic
architectural units should be, although ideas abound. At least we should
recognize what the fundamental problem is before we grope for more solutions.
Hope I've shed some light on the phenomenon of light-weight processes.
-- Al Mok