paper

Syed Adnan (sadnan@ucsd.edu)
Thu, 11 May 2000 07:34:21 -0700

Name: Syed Adnan
Date: 5-11-00

Experience with Processes and Monitors in Mesa

Paper discusses the problems and experiences with processes and monitors in Mesa language. Paper talks about the problems with the use of monitors, which must be dealt with. Few problems that paper mention are the semantic of nested monitor calls, problems with nested monitor calls, priority scheduling, handling of timeouts, exceptional conditions, and interactions with process creating and destructing.
Paper talks about all these problems with a system using Mesa language. Paper did talk about processes and properties of scheme that it uses in dealing with processes. Paper mention that mesa casts the creating of new processes as special procedure activation which executes concurrently with its caller. Paper claims that using this scheme a process can be assigned as a value to variables and passed in as parameter to procedures. Passing of parameters would very similar as methods of corresponding procedure. No special declaration is needed for procedure, which is invoked as process; the cost of creating destroying process is moderate. With larger number of processes in a system synchronization becomes more difficult. Processes also create dangling references. Paper introduces the idea behind monitor in this system, which is to unify synchronization, and shared data issues in system. To start off with monitors have problem that a random order is much more efficient and needed wh
en accessing monitors. For example, a tape with reverse and read functions could stuck on reverse that reverse locks on, and just wait for read but in order to read it first reverse need to release the lock. Paper didn't suggest any solution to this problem.
Paper talks about deadlock issues when using monitors, and paper after giving few examples of how dead lock could occur (for example a cycle among processes), and paper claims that programmer should be careful to avoid such situations. Paper really didn't talk about any mechanism built in the system to prevent deadlocks.
Paper mentions many small objects sharing data, and we could just use one monitor for that, but it could be a problem. Replication of same monitor is suggested, but there is cost attached to it.
Paper talks about semantic of wait, and wait requires singling system to be very reliable. For singling, paper talks of different predicates to implement singling more efficient and reliable. Notify uses, timeout, abort and broadcast singles to notify waiting processes more efficiently. Priorities are discussed using monitors, and scheme that paper talks about is that associate with each monitor the priority of highest-priority process which ever enters the monitor.
Implementation of monitors is mention in paper. It is split equally among mesa compiler, the runtime package, and the hardware. Process said to exist only on stack, and paper talks about the process state and frame heap, which describe the process on stack. Queues keep track of process states, and process is aware of these queues. These queues use monitors for locking and unlocking the cells.
Paper goes over pilot operating system, and it mentions two different problems. Pilot experienced the lack of mutual exclusion in the handling of interrupts, and the interaction of the concurrency and exception facilities.
Over all, paper claims that they were able to add all the new functionality. This is a good paper to learn from the details and issues of monitors.