cse221: paper evals

Octavian Luca (oluca@cs.ucsd.edu)
Thu, 20 Apr 2000 04:15:32 -0700 (PDT)


The paper discusses StarOS, a multiprocessor operating system that is
object-oriented, message based, and specifically designed to support task
forces. The authors define task forces as software composed of many
cooperating smaller processes and their supporting code and data meant to
accomplish a single task. Their research is interesting because they
designed an operating system specifically meant to take advantage of the
multiprocessor architecture through inherent processing unit cooperation.
It seems that their approach differs from previous work in their decision
to base their system around the concept of task forces and their unique

The approach they used in the design of the system stems from goals of
improving in cost-performance, reliability, and hardware adaptability. To
this end they attempt to take advantage of the multiprocessor environment
to maximize performance by optimizing both hardware and operating system
to implement task forces that bring together hardware and software
resources running in parallel wherenever possible. It seems that they
first formulated the task forces idea, and then proceeded to adapt it to
run on their 50 processor machine. They places special emphasis on
designing a system that scales well by adding hardware resources of
processors and memory. The system maximizes hardware performance through
flexibility, as it allows task forces to use multiple processors in
parallel when running algorithms that allow parallelism. At the same
time, tasks that cannot run in parallel can be tackled by a single
processor, thus eliminating the extra overhead of inter processor

The goal of their research is to evaluate whether the task force software
takes advantage of the potential benefits of multiprocessor system. At the
time this paper was written the implementation of their system was barely
finished, and they just started with the evaluation stage of their
research. Therefore they could not provide answers to their questions.
Also they did not provide details about the evaluation methods of the
system, as their focus was on explaining the indeas behind the design and
implementation of the system.

>From reading this paper I learned about pertinent issues that need
consideration when designing multiprocessor sytems, and how to adapt one's
goals when switching between hardware with different capabilities
(uniprocessors vs multiprocessors). This paper seems to be one of the
precursors of current work in the multiprocessor systems field.


This paper aims to build upon the knowledge aquired from the design of
StarOS. Medusa retains from StarOS object oriented properties as well as
system design based on concept of task forces of cooperating activities.
However, whereas in the design of StarOS emphasis was placed on providing
a set of flexible high-level facilities sometimes at the expense of
efficiency and performance, the focus of Medusa was on the opposite.
Medusa attempts to optimize for efficiency and performance by closely
matching system structure to the distributed nature of the hardware. This
approach is advantageous to reaching this new set of goals as the
distribution of the system accross the multiple processors in utilities
that run fast on only one CPU avoids slowdowns derived from inefficient
inter processor communication. Thus, Medusa has attempted to achieve
performance, modularity, and robustness by adopting at it's lowest levels
distribution and concurrency.

The designers attempted to reach their goals this time around by
reevaluating previous assumption based on the results obtained from the
StartOS experiments. As pointed out in the previous paper, the system
neatly facilittates concurrency through the use of task forces as a
central design concept. Since the task forces can distribute independent
sections of code into different activities that can be run in parallel on
multiple processors. The system robustness is assured by creating hard
boundaries between activities performed on separate processing units,
insuring minimal disruptions of processors not directly involved in a
crash. Performance is assured through policies meant to minimize inter
processor communications and data sharing as much as possible by retaining
data close to it's processing unit.

This paper revealed ways to critically evaluate previous work, and how one
could go about evolving further designs from data obtained from earlier
experiments. Also it is important to focus on the goals of each
experiment and obtain as much insight as possible so that further work can
rely on the lessons learned to devise experiments meant to reveal further
insights into system design.