Paper evaluations for 4/20...

John Michael U. Datuin (
Thu, 20 Apr 2000 08:28:07 -0700

The StarOS paper described the StarOS OS, which was an experiment to
design an OS that was message-based, object-oriented, supported this notion of task forces,
and to take advantage of the hardware architecture of the Cm* system to
perform multiple, parallel processes for the purpose of completing some single
task/computation. The OS was designed with the 3 goals being cost performance,
reliability, and adaptable to changes.
It's interesting to see that StarOS borrowed some ideas from Hydra, such as
the notion of capability for providing access to objects within the system, but that
a kernel entry is not required to read/write the data in objects.
The use of mailboxes in StarOS for interprocess communication is interesting. One
would think that this message passing approach would be expensive in the amount
of messages being passed around the system if there were a lot of processes.
Overall, the StarOS paper was an interesting paper. Though it appears to be alot
of overhead in the fact that the nucleus is copied to all computer modules in the
system, I guess it was necessary for the sake of reliability, as the authors noted.
One area which I wished the authors discussed is how they handled StarOS
managed memory; with all the processes being created/killed depending
on the load of the system, and with such OS functions like KILL, one would think
that memory would be a fragmented mess.

The paper on Medusa was an interesting paper. Medusa was based on
StarOS, but instead of the goal of accomplishing a single high-level task with multiple,
parallel processes, Medusa focused on the distributed nature provided by the
hardware; the design for Medusa was not motivated by the need to perform a
task, but to be modular, robust, and performed well.
Medusa used the notion of utilities, which are basically functions, and task
forces (similar to that in StarOS) which a utility is a task force. The interesting
thing about Medusa, compared to StarOS in that StarOS copied the nucleus
to each computer module in the system, the Medusa OS was divided into
utilities. These utilties were distributed in the system and message passing
was done by a processor to another processor if the calling processor couldn't
invoke a utility function but the called processor could. The authors called
this fixed control information; a program moves from processor to processor
to gain access to information or to have a function invoked on the processor
that contained the information or could invoke the function.
Medusa used descriptors to access objects, where the descriptors were
kept in a descriptor list. Another feature of Medusa is its exeception reporting.
Medusa contained this notion of a buddy, which is some routine/process that
executes when one activity in a task force produces some sort of exception.
The neat thing about the buddy is that it can execute behind the scene of the
activity that produced the exception, resolve the exception, and the activity
can continue. But looking back, it just looks like a "smart" exception handler
that was created to look for that particular exception. One would have to
write a lot of buddies if most exceptions would want to be handled behind
the scenes.