CSE 221 Paper Evaluations

Greg Johnson (johnson@SDSC.EDU)
Wed, 19 Apr 2000 21:36:13 -0700 (PDT)

MEDUSA: AN EXPERIMENT IN DISTRIBUTED OPERATING SYSTEM STRUCTURE
J. OusterHout, D. Scelza, and P. Sindhu, 1980

Medusa is a modular operating system for use on the Cm* shared memory
multiprocessor. The Medusa design focuses on three goals: modularity,
reliability, and performance.

A note about the hardware. A side effect of the cluster nature of Cm*,
is the rise of non-uniform memory access as a serious issue to contend
with. The authors state "a rule of thumb is that local hit ratios should
generally be 90 percent or better to avoid serious performance degradation."
This factor plays a key role in the design of Medusa. In particular, the
components of the OS (utilities) are distributed throughout the memory in
the machine. Further, a given processor may only execute a utility if it
exists in local memory. This suggests that control flow within a program
moves across different processors (depending on the utilities it requires)
through the course of its lifetime. Remote functions are invoked using a
message passing scheme.

This design also moves Medusa in the direction of a third design goal
(performance and modularity being the first two), that of reliability.
Interoperation between utilities (and user activities) is well defined,
and message passing is dangerous only to the receiver (who alone controls
when a message is received). In addition it's conceivable that multiple
instances of key utilities are run simultaneously in different locations
in the system, providing redundancy.

Like StarOS, Medusa utilizes an object model. Access to objects takes
the form of descriptors. Reliability (and performance and modularity)
of the system is further enhanced by storing descriptor information for
a particular activity in a structure local to the processor performing
that activity. Systems which store such key data in a central location
are vulnerable to loss of either the software or hardware in the region
of the machine supporting that repository.

---------------------------------------------------------------------------

StarOS, A MULTIPROCESSOR OPERATING SYSTEM FOR THE SUPPORT OF TASK FORCES
A. Jones, R. Chansler, I. Durham, et al., 1979

This paper describes the design of an object-oriented operating system
for shared memory multiprocessor clusters. Many of its features focus
on leveraging the advantages of parallelism, including fault tolerance,
concurrent processing, and adaptive processing (assigning additional
processes to tackle high demand for a given function, or when additional
hardware becomes available - unimplemented).

Execution of a parallel task in StarOS is accomplished by a collection
of processes known as a task force, the size of which is determined by
availability of resources. This is different from a typical UNIX driven
shared memory multiprocessor of today. Here, a task consists of several
threads, and the mapping of threads to processors is unbounded.

In several respects StarOS is similar to Hydra. Both were designed for
use on shared memory multiprocessors, and both operate on objects. In
addition, both limit access to objects through the use of instances of
permission called "capabilities" (though the Hydra model offers greater
flexibility). Unlike Hydra, StarOS utilizes an "immediate" addressing
mode in which the processor directly accesses the data in an object (in
Hydra all such access goes through the kernel).

Another departure from Hydra is the use of message passing for inter-
process communication in StarOS. In StarOS, a sending process lodges
a message in a "mailbox" object for use by a registered receiver process.
In Hydra, two processes may be granted access to the same data.

Something I found interesting about this paper is the notion 21 years
ago of developing faster machines based on collections of commodity
parts. I tend to this of this as a more modern idea, one which came
into fashion with the development of massively parallel computers in
in the late 80's.

On a stylistic note, I found this paper a bit difficult to go through.
Every other sentence seemed to introduce a new type of object, and it
became difficult to keep types and usage straight.

=============================================================================
Greg Johnson office: (858) 534-8367
Senior Programmer Analyst fax: (858) 534-5152
San Diego Supercomputer Center email: johnson@sdsc.edu
University of California San Diego