cse221: paper evals

Octavian Luca (oluca@cs.ucsd.edu)
Tue, 25 Apr 2000 03:48:09 -0700 (PDT)

Duality of OSes

This paper discusses the dual nature of two approaches to sound operating
system design and argues that the approaches can be mapped onto each
other. First considered is the message-oriented approach, characterized
by relatively small, static number of processes that communicate via an
explicit message system. Secondly, the procedure oriented approach
involves a large, rapidly changin number of small processes that are
synchronized using shared data. The topic of this paper is important
because of its attempt to review and analyze inherent properties of
operating system design approaches that proved successful. This paper
differentiates itself from previous work by focusing on the evaluation of
high level design approaches rather than describing design decisions
motivated by a specific hardware configuration or system design goals.

The paper uses an empirical approach to investigate an universe composed
of the classes of operating systems, specifically focusing on the ways in
which processes, synchronization, and interprocess commuication happen
within these systems. It first describes a cannonical model for the
message-oriented system, highlighting it's major features, basic system
primitives, and an implementation example of the use of system primitives.
Then the procedural-oriented system is given similar treatment. Based on
the previous descriptions, a "duality mapping" is formulated to express
the direct mappings between concepts and primitives from one approach to
the other. Then the authors argue that performace is preserved by proving
that execution times of the programs are independent of the OS approach
used, that the overhead imposed by the primitive system of both are of
similar complexity, and that the queueing and waiting times are dependent
on external events and scheduling policies not on the design approaches.

>From reading this paper I learned that the design of an operating system
should be based on optimal utilization of given hardware rather than a
task to be performed since both approaches lead to similar performance.
Thus, all things being equeal, performance benefits can only be obtained
by choosing the approach that most efficiently maps itself to the
underlying hardware. Overall the paper makes some interesting points, but
it seemed to me that it did so in a very redundantly repetitive manner
with passages that were sometimes reiterations of previous points.

Structuring using Upcalls

This paper proposes an operating system implementation methodology that
permits synchronous communication beteween layers using so-called
"upcalls". This approach is inspired by network protocol design where
layered designs proved to perform best in terms of speed and efficiency.
This paper attempts to extend this approach to designing general purpose
systems. This is an important problem because it attempts to improve
current system design by observing where improvements can be made, and
attempting to formulate a design that takes advantage of these
observations while avoiding problems derived from it's unorthodox nature.
The basic idea around which the paper is centered is that control should
flow from bottom to the top in addition to the normal top to bottom
approach. This, in tandem with synchronous support for multi-task
modules, is claimed to lead to great efficiency and speed benefits since
the need to maintain queues of messages (like in other systems) does not

The paper goes on to prove that this method does indeed offer the claimed
benefits by detailing the mechanisms implemented for the Swift OS, and
explaining how layering and upcalls work together in the context of the
afore mentioned kernel. The multi-task module is of particular importance
in this system as it allows subroutines in different tasks to collaborate
with each other through shared states. The innerworkings of such a system
are exemplified in the implementation of a network protocol which
perfectly fits with this design approach. Advantages of this approach
such as cost savings due to abbsence of buffering mechanisms for IPC, and
ability to upcall for advice are discussed in detail. Problems such as
recovering from a failed upcall or indirect recursive calls, that arise
from using upcalls are also discussed and pertinent solutions are offered.

This paper's main contribution is to exemplify a way of identifying system
inefficiencies, and to propose solutions that sometimes contradict
previously held beliefs of good system design. It also shows the
importance of insuring that any new such solution has to be tested so that
if it introduces new design problems, those issues are considered and
accounted for in the final design.