Presentation Summary of “Experiences with Processes and Monitors in Mesa” By Burke Ellett
What I will cover today …
Mesa programming language and design decisions when adding concurrency.
Difference between Hoare’s monitors and Mesa monitors.
Issues that caused problems during the development of Pilot and other large processes
Benefits and drawbacks to having concurrency implemented inside of a language construct
What is Mesa?
Mesa is a strongly-typed high-level programming language, a component of the Xerox Development Environment . 
It was developed at Xerox PARC in the 1970's 
It was used to develop systems software for the first personal computers and spurred the development of the Lisa and Macintosh computers, whose user interfaces in turn prompted the development of Microsoft Windows. 
Oldest relative of Java
Motivation for adding concurrency to Mesa
The creation of Pilot which was the first operating system developed for personal computers that would allow for multiple processes to run concurrently where each shared a time slice of CPU. Created using concurrent programming as opposed to event based programming.
Add concurrent programming to Mesa so that side by side development of Pilot could take place.
Choices for handling concurrency in a language
Voluntary yields was an option that was rejected
Only good for single processor
Must respond to time critical events so preemption needed anyways
Restricts programming generality, you need to know if a procedure you call will yield the processor
Page faults would cause involuntary yields at arbitrary points in a program
Message passing was an option that was rejected because it was proven to be equivalent to monitors when some mild restrictions are applied
Monitors was the final choice because it was equivalent to message passing and worked better with the procedural scheme of Mesa, they choose Hoare’s paper as a starting place for thinking about concurrency in their language.
Issues about adding concurrency to Mesa so that Pilot could be developed
Wait in a nested monitor call
Communication with devices (like I/O)
Creation of a process in Mesa
Any non-internal monitor procedure can create a new process by the use of a new key word called FORK that is placed in front of the procedure call
This FORK procedure call will allow the current process to work concurrently with the new process created. It also returns a reference to the process just created so that the parent process can later joined an a result is returned or to detach from it. Different then Hoare thread that must suspend working until to the thread just created exits or yields.
P ←FORK ReadLine[Terminal];
… <concurrent computation>
buffer ← JOIN p;
Every thread can be joined at a later time unlike PThreads where you need to specify at time of creation. Extra overhead in Mesa thread even though in practice most Mesa programmers will immediately detach the thread.
Reasons for this syntax for creating processes
Made a process a first class value
Method of passing and retrieving values to a new process the same as a normal procedure
No special declaration needed for procedures that can be invoked as separate processes, similar to PThreads
Low cost of creating and destroying processes allowed for number of processes to vary widely at any time
Start the new process working at the beginning of any procedure
A Mesa module (Similar to a class) contains shared data and procedures to act on the data as well external procedures that do not modify the data (Diff. than Hoare that has no external procedures)
A module can be declared a monitor module which contains three type of procedures
Entry (Monitor required procedures called externally)
Internal (Private procedures may be called by entry procedure)
External (Non-monitor procedures)
A lock must be obtained by a process that calls an entry procedure and is released when the entry procedure exits. The lock is implicit and the runtime environment handles management of this. Therefore a Mesa monitor is an instance of a module.
No explicit creation of a locks unlike in PThreads.
Problems with this implementation
Upon entering a Entry procedure you might find you need to wait (Like consumer/producer problem)
Exception thrown by this procedure or a sub-procedure who releases the lock
Recursive entry procedures
Calling an Entry procedure of another monitor-module from inside a monitored procedure
Adding the WAIT key word
WHILE NOT <OK to proceed> DO WAIT c ENDLOOP. (Mesa and PThreads)
IF NOT <OK to proceed> THEN WAIT c. (Hoare)
NOTIFY key word
When one process establishes a condition for which some other process may be waiting it notifies the corresponding condition variable
It is like a hint to a single waiting process to resume at some convenient time, not a guarantee that the condition waiting on will be true (Different the Hoare)
Alternatives to NOTIFY are TIMEOUT, ABORT, BROADCAST
Hoare Semantics for condition variable wakeup 
Mesa Semantics for conditional variable wakeup 
Implementation of processes and monitors
Split between compiler, runtime package, underlying machine
A process is represented by stack of procedure activation records (frames) plus a small description called a process state
Frames are stored on the heap and a frame handler is invoked if a fault occurs
Process state is stored in fixed table which consists of four types of queues
Monitor lock queue
Condition variable queue
Queue cells point to the tail process state in a circular link list of process states
The queue is priority sorted and within each priority group a FIFO algorithm is used to decide the next running process
A process not held in the ready queue could be passed to the processor through software instructions or a trap vector center in the case of a page fault
The Process module of the Mesa runtime package handles all of this including notification of processes waiting on a time interval
Priority Scheduling can Cause Blocking
The paper example of possible blocking caused by priority scheduling (same as last week)
P1, P2, and P3 are processes with priority same as subscript, with monitor M.
1. P1 enters M
2. P1 is preempted by P2
3. P2 is preempted by P3
4. P3 tries to enter monitor and waits for lock
5. P2 runs again and effectively prevents P3 from running contrary to priorities
Mesa uses priority scheduling but assigns each monitor the priority of the highest priority process which ever enters that monitor to ensure the CPU priority scheduling discipline imposed by some application, thus preventing blocking in example above.
Handle I/O interrupts for condition variables
Since I/O device does not wait on a monitor it notifies the condition handler when it needs attention. This is called a “Naked Notify” and can lead to a race conditions
If a process inside the “while not <condition> do wait” loop and has checked the condition and is preparing to wait at the same time the interrupt occurs then the notify could become lost and the process may not wake again.
Fixed with wakeup-waiting switch in condition variable (binary semaphore)
New key words
More static checking to find frequent errors like the use of wait in an external procedure (external procedures have no knowledge of locks that are held)
The only major performance issue was the FORK-JOIN construct which resulted in over 10 times the amount of time ticks as any other construct or the same time as 1100 simple instructions
The cause was the implementation of this in software, but since it is not in popular use they left it there
Problems encountered with Mesa implementation of concurrency
The lack of mutual exclusion in handling of interrupts (Bugs caused in timing races between I/O and handlers
The interaction of concurrency and exception handling makes programming hard
Implement concurrency in language or not
Main advantages is the programmer has direct guidelines for the syntax and behavior of the threads, the program should work the same from computer platform to computer platform so more portable, far easier to use a standard package
Main disadvantages are that the programmer loses the ability to take advantage of hardware, by having built in concurrency you lose flexibility of interleaving different libraries that handle concurrency favorable to your particular problem
Contributions to community
Though neither Mesa or Pilot ever took off it was the launching point of both the modern personal computer and the ideas behind the use of virtual machines like Java
Tied up many loose ends in concurrent programming and got them implemented into one package
Helped define basic implementations of a modern OS
http://www.apearson.f2s.com/mesacourse10.html A website about the Mesa programming language, and its history.
“ Monitors: An Operating System Structuring Concept” by C.A.R Hoare,The Queen's University of Belfast
“ Pilot: An Operating System for a Personal Computer” by David D. Redell, Yogen K. Dalal, Thomas R. Horsley, Hugh C. Lauer, William C. Lynch,Paul R. McJones, Hal G. Murray, and Stephen C. Purcell, Xerox Business Systems
Duke University Systems and Architecture class slides