Evaluations: 05/11

Bianca Zadrozny (zadrozny@cs.ucsd.edu)
Thu, 11 May 2000 08:09:40 -0700

Monitors: An Operating System Structuring Concept

This paper introduces the usage of monitors as a synchronization mechanism for structuring operating systems. A monitor is a collection of data and procedures, with the property that only one program at a time may be executing a monitor procedure. Moreover, the data inside the monitor can only be accessed by the monitor procedures.

In order to delay a process that wishes to acquire a resource that is being used by another process, the paper introduces the concept of condition variables. A condition variable is implemented as a queue of processes that are waiting on a determined condition. The operation "signal" is used to resume the execution of a process waiting in the queue, and the operation "wait" is used to delay the execution of a process by inserting it into the queue.

The paper shows how to implement semaphores using monitors and vice-versa. This shows that monitors are as powerful as semaphores, while providing a higher-level of abstraction by encapsulating code and data. The paper also gives practical examples of the usage of monitors, including concurrent buffer allocation, scheduled waits, readers and writers and a disk head scheduler.

I learned from this paper that it is very important to think about invariants when using monitors. In order to keep the local data consistent for every process that enters a monitor, it is necessary to make sure that the invariants hold before every "wait" instruction, since the monitor lock is released when "wait" is called and other processes may enter the monitor.

One problem with this paper is that it does not address the issue of how to implement a real operating system using monitors as a basic synchronization mechanism. It actually makes a point that it is difficult to decide how to separate operating system functionality into independent monitors. Another problem is that the approach presented in the paper leaves the responsability of avoiding deadlocks entirely to the system programmer.


Experience with Processes and Monitors in Mesa

This paper describes the mechanisms for concurrent programming using monitors in the programming language Mesa. In particular, it lists a number of design and implementation issues of monitors that were not covered in previous research, and that arise when implementing monitors in a real system, providing solutions for them. Among these issues are process and monitor creation, scheduling, and the semantics of exceptions, input/output and "wait" in a nested monitor call.

The choice of integrating the monitor facilities into the Mesa language was motivated by the fact that it was used as the basis of a single-language operating system: Pilot. In this way, monitors will be available for both the system and applications. Furthermore, many types of errors could be detected by the compiler.

One important difference between monitors in Mesa and Hoare's monitors, is that the signaling operation for condition variables is asynchronous. Thus, the number of context switches is reduced, since the signalling process is not automatically preempted. However, when the waiting process resumes it must reevaluate the condition, since another process could have changed it after the signal. Because this choice was made, it was possible to define other ways of signalling processes, including broadcast, which causes all the processes waiting for the condition to resume, and timeout, which causes a process waiting for a condition to resume even if the condition has not been signalled.