evaluation5

Albert Xu (xualbert@yahoo.com)
Thu, 20 Apr 2000 01:27:10 -0700 (PDT)



__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com Evaluation of StarOS

StarOS, developed at Carnegie-Mellon University, is a message-based, object-
oriented, multiprocessor operating system, specifically designed to support task forces.
Three benefits are: increased cost-performance, enhanced reliability, and
hardware adaptability.
Task force is a important concept in StarOS. Itís a large collections of
concurrently executing processes that cooperate to accomplish a single purpose. One
interesting feature of task force is that task force is the unit of responsibility for any
functionality other than the most primitive. For example, Itís the unit of accountability
and the unit for which major resource scheduling decisions are made.
As an aid for the constructing of task forces, StarOS supports the TASK
languages. The authors distinguish between the executable task force and the static task
force. Also, they present StarOS itself as an example task force.
Cm * hardware features include: Cm* consists of clusters. Cluster consists of
computer modules, Kmap and Map Bus. Kmap is multiprogrmmed, it mediate each
processor reference place on the Map Bus. Memory is organized in a performance
hierarchy.
StarOS is object-oriented, all information is encoded and stored in objects.
Objects are typed. All objects are distinct and unique. Capability is used to access an
object. In these ways, itís very similar to other object-oriented OS like hydra.
StarOS is message-based. Event mechanism, Mailbox, Send, Receive, Block
primitives are quite familiar concepts today.
The scheduling in StarOS is done by schedulers and multiplexor. In fact they
embody the idea of the separation of mechanism and policy.
StarOS instructions refer to those functions that are performed sequentially with
respect to their invoker. Collectively, the StarOS instructions are called the nucleus and
they define the sequential portion of the abstract machine that StarOS provides to its
users.
A benefit of dynamic reconfiguration is that it can be exploited so that the system
may recover from hardware or software failure.

StarOS architecture is tightly connected with the hardware architecture. I donít
find in the paper that the authors pay any special efforts to the portability. I think itís not
easy to port StarOS to other machine. From todayís viewpoint, itís a big deficiency
because hardware becomes cheaper and cheaper, the percentage of the cost of system
software in the whole system becomes higher and higher.
Finally, according to the meaning of the naming rule, it looks like that the names
Cm+ and PlusOS are more reasonable than the names Cm* and StarOS.?. Can an OS
be designed or work with nothing?


Evaluation of Medusa

Medusa, an object-oriented, distributed operating system, is the second operating
system for cm* multimicroprocessor which combines distribution and sharing. The first
one is StarOS. Medusaís goal is to exploit the underlying hardwareís feature to produce a
modular, robust and efficient operating system. To realize its goal, Medusa discards the
assumption of all other operating systems at that time that all operating system code may
be executed from any point in the system because traditional operating system
approaches have two major problems: performance and reliability.
The combination of distribution and sharing in the hardware gives rise to two
corresponding software issues: partitioning and communication. Medusa is partitioned
into several disjoint utilities that communicate via messages. All programs, including the
utilities, are task forces to take advantage of the parallelism in Cm* and to provide
robustness.
Cm * hardware features include: computer modules, Kmap, and Map Bus
comprise of cluster. Cm* consists of clusters . Kmap is multiprogrmmed, it mediate each
processor reference place on the Map Bus.
Medusa tries to eliminate all interactions between utilities except those absolutely
necessary for them to function. Pipe and return pipe in Medusa limits damage and
permits transparent system reconfiguration.
Two often overlooked portions of operation systems have been formalized in
Medusa by making them utilities: the exception reporter and the debugger/tracer.
A little trick used in Medusa to avoid wasteful context swaps is concept of pause
time.
The sharing of address space is done through an XDL. The amplification
technology is useful to access protected object.
The internal structure of a utility activity is very interesting. Itís designed to
avoid deadlock and to avoid unnecessary waiting at the same time. It gives a feeling of
multithreading.

In summary, Medusa is a very interesting operating system. To focus on
distribution and communication, it sacrifices some fine grain of protection and generality
of task forces compared to StarOS.
Also I think portability is a big problem in Medusa since it attempts to closely
match its structure with the hardware.