Evaluation #5

qin Zhanhai (qinzhan_hai@hotmail.com)
Thu, 20 Apr 2000 15:11:31 GMT

Hi, Geoff,

Attached please find the evaluation #5.


Zhanhai QIN
Get Your Private, Free Email at http://www.hotmail.com
Evaluation #5, CSE221


StarOS, a Multiprocessor Operating System for the Support of Task Forces

Potential benifit of StarOS:
1. Increased cost-performance-decompose for maximum parallelism;
2. Increased reliability
3. A physically adapable computer-separately addressable data and codes;

task forces
A task force is a collection of processes working for a single task.
It may correspond to a subroutine in traditional multiprogramming
systems. It's the unit of responsibility for any functionality other than
the most primitive. It's the unit of accountability and the unit for which
major resource scheduling dicisions are made.

Cm* architecture
The computer modules, Kmap, and Map Bus together comprise a cluster.
Clusters are connected via Intercluster Buses running between the Kmaps.

StarOS architecture
System introduces multiplexers and schedulers to achieve maximal
parallelism whenever possible. So StarOS is message based.
Communication is based on mailbox type.
From a behavioral point of view, a module defines and exports a set
functions for use by code in other modules. From an implementation point
of view, a module is an object containing capabilities for those code
and data objects shared by the processes executing the function of the
Schedulers and multiplexers are responsible to processes and each
process, respectively. In other words, schedulers are working on a higher
level than multiplexers are. So multiplexers could be more specific.
All functions are asynchronous except functions defined for
types and those being explicitly claimed sequential with respect to their

Nucleus of StarOS
The nucleus of StarOS is its instructions. it locates at the kernel
address space and appears to run as a standard process. And for reliability
and performance, the nucleus generally is copied in each module's memory.

Pro's of StarOS
1. The consistent use of typed objects and capability-based authorization.
2. Interface uniformity.
3. Preservation of the multi-processor aspects of Cm*.
4. Allocation of overheads.
5. Programmable at a high level by users.


Medusa: An Experiment in Distributed Operating System Structure

Medusa emphasizes modularity, robustness and performance as its
ultimate goals as a distributed operating system. And due to the features
of Cm*'s architecture, in particular its distributed arrangement and its
strong communication ability, Medusa has two corresponding significant
characteristics: distributed control structure and implicit parallelism.

In stead of duplicating a whole nucleus for each processor, Medusa
separates its nucleus into disjoint utilities and distributes them among
the available processors. A processor executes a particular utility only
if it can do so locally. Medusa uses message machanism to solve
boudary function invocation. The approaches are attractive because making
processors run locally is very efficient. And message communication is
side effect because the only effects it has on the receiver are those caused
by the receiver. The use of pipes both limits damage and permits transparent
system reconfiguration.It's some concepts like O-O programming. But the side
effect of the approach is that how to partition the nucleus into disjoint
utilities and make each processors with these utilities have balanced work

The task forces are almost the same as those in StarOS. They call
capability in StarOS as descriptor. Medusa devides descriptor lists into
two classes: one is private descriptor list(PDL) and the other is shared
discriptor list(SDL). And Medusa places PDLs every executable processor
separately. This enhences reliability.

The standard solution to deadlock has been to allocate the requested
resources dynamically from a large central pool. It's infeasible for Medusa
as a distributed OS. The solution in Medusa is to structure utility
as collections of coroutines or proceseses.