Monitors Evaluations.
Thu, 11 May 2000 04:27:25 EDT

Monitors: An Operating System Structuring Concept

The paper talks about monitors, why do we need them and how to implement them. Programs that use similar resources have to schedule their access to the resources to guarantee its safety (in execution) and maintain a state that can be manipulated by one program at a time. Monitors are the solution to schedule the different accesses to resources. The mutual exclusion on the code of a monitor insures that the programs follow each other in order. Condition-variables in monitors substitute for semaphores ( as while-loops for jumps).
Similar monitors can be defined in classes and each one of them can be only entered by one program at a time. The local data in monitors are private to that monitor. Synchronization for the accesses is implemented using the wait and signal “operations”. If a program uses a resource, it sets a condition variable that can be examined by next requesters in order to know why they are waiting, and then they are placed on a queue for each condition. The using process should signal, as a last operation he does before exiting, meaning that he is done and the longest waiting process in the queue would be selected to use the resource. In fact, a scheduled wait can be done if we want to give different priorities for processes to wait, however, this requires the insurance of no thrashing or other similar problems. Monitors should view the resources of the entire system. This way, deadly embrace can be avoided and the monolithic monitor would be able to make decisions close to!
Monitors simulate boolean semaphore. The authors constructed each one from the other showing how they are equivalent. The author has given different examples that I find really meaningful and straightforward. Monitors are easier to use and maintain by programs than simple semaphores. The thing I like most about this paper is the scheduled waits. It gives power in a multiprogramming environment and I wonder if they still exist. Also, I hope you can point out what happens in a shared free buffer pool. As I understood, when the consumers are slow, the pool is empty ( all buffers hold some data). Assume that at that time all consumers died ( buffers still reserved), and further assume that a new producer/consumer came in where the consumer need to read, lets say, 5 buffers at once. How would this be resolved?

Experience with Processes and Monitors in Mesa
The paper deals with constructing monitors in big real life operating system. The work done on monitor construction did not answer all the problems that might rise in real life construction. This paper describes the methodology that the designers took in implementing the Mesa language and the Pilot operating system. The designers of a system have to come up with the best design solution they can to meet with their goals of the system.
The authors choose to implement the interprocess communication paradigm based upon message passing since the procedure is their main tool for program structuring in Mesa. The duality of the two schemes, message passing and shared memory, made them in favor of the one that they already support. The nonpreemtive scheduler for the shared memory was rejected since it did not go well with their system.
The parent process may detach processes. This can result in dangling references, which the language provides no support for. An UNWIND operation gives a chance for the processes to clean before they terminate (case of exceptions). Monitors have three types of procedures. The external procedure is accesses without locking the monitor. When a process exits the monitor, many processes can be waiting with no guarantee on which one will use it next. Authors impose that higher levels should emphasize such a schedule of use in the system. There may be several kinds of deadlocks, based all on three patterns, and each one of them has been given a solution to avoid it.
Signal ( Notify ) is taken as a hint since processes are assumed to be cooperative. The awakened process does not have to execute immediately. This gives no constraint on which process will use the monitor later. In general, there are four ways to wake up a process: abort, broadcast, timeout and naked notify. Still, there is no why to stop a running process!!
Priority scheduling may be developed and care must be taken to avoid its problems ( I do not think they used it in Mesa ). The implementations of the Mesa language and the operating system are split equally between the Mesa compiler, the runtime package and the hardware , based on the amount of use of the operations. Some examples are given here too to explain the implementation of the monitors.

The paper itself:
I really really really hate this paper. I spent so much time on so many details, and still do not know how did they do it or why did they do it this why! I guess it had many details of implementation instead of having many different ideas ( which would have been hard to, but at least understandable!)

Sobeeh Almukhaizim