CSE 221: Paper evaluations

Renata C TEIXEIRA (teixeira@cs.ucsd.edu)
Wed, 10 May 2000 20:07:22 -0700 (PDT)

Title: "Monitors: An Operating System Structuring Concept"

This paper proposes structuring the operating system using monitors
in order to ensure synchronization in the accesses to resources. A
monitor is a collection of associated data and procedures in which
only one program can enter in a monitor procedure at a time. Monitors
have a new type variable, called conditional variables. A conditional
variable express one reason why a program may need to wait.

The paper shows that semaphores can be implemented by monitors and
vice-versa. Monitors can be used to synchronize: cooperating
processes (bounded buffer), readers and writers, disk head movements,
etc. Conditional waits may be given priority. In this case, the
program that specified the lowest priority is resumed at each
signal. Conditional waits with priorities can be used to implement
alarm clocks.

I think that conditional variables are a simple and generic mechanism
that can be used in a variety of problems, and the decision of keeping
them as simple as possible was an important contribution of the paper.
These mechanisms, however, should be used carefully by the programmers,
otherwise deadlocks may occur. Furthermore, if a process is aborted,
there is no mechanism to free the resources it was using.
------------------------------------------------------------------------

Title: "Experience with Processes and Monitors in Mesa"

This paper describes processes and monitors in the Mesa language to
support for concurrency in the Pilot operating system. Since Pilot
was written in Mesa and all Pilot's applications have to be written
in Mesa, the paper proposes integrating monitors in the language
instead of in the operating system itself.

A monitor in Mesa is an instance of a module that has three different
kinds of procedure: entry, internal, and external. The first two
are monitor procedures, and execute with the monitor lock held.
Monitors should be used carefully in order to avoid deadlocks.
When an exception occurs in a procedure the programmer must supply
a handler. If the procedure is an entry procedure and a handler is
supplied, Mesa will automatically supply the code to release the
lock.

Conditional variables in Mesa don't require that processes waiting
on the variable must run immediately after a notify. Instead a
notify is regarded as a hint to a waiting process. Mesa also provides
three additional ways to resume a waiting process -- timeout, abort,
and broadcast -- and naked notifies, used for processes communicating
with devices.

I think that integrating monitors in the language can reduce the
number of runtime errors by performing compile-time checks. The
different semantics used to notify processes is also interesting
because it allows different ways to resume waiting processes and
avoids unnecessary context switchings. The drawback of this approach
is that only one language can be used.

Renata Teixeira