cs533 - concepts of operating systems 1 presentation summary of “experiences with processes and...

CS533 - Concepts of Operating Systems 1

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. [1]

It was developed at Xerox PARC in the 1970's [1] 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. [1]

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 rejectedo Only good for single processoro Must respond to time critical events so preemption needed

anywayso Restricts programming generality, you need to know if a

procedure you call will yield the processoro 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

Program structure Creating processes Creating monitors Wait in a nested monitor call Handling exceptions Priority scheduling 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


Creating monitors

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

o Entry (Monitor required procedures called externally)o Internal (Private procedures may be called by entry

procedure)o 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)

-versus-

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 [4]


Mesa Semantics for conditional variable wakeup [4]


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

o Frames are stored on the heap and a frame handler is invoked if a fault occurs

o Process state is stored in fixed table which consists of four types of queues

• Ready queue• Monitor lock queue• Condition variable queue• Fault queue


The queues

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 M2. P1 is preempted by P23. P2 is preempted by P34. P3 tries to enter monitor and waits for lock5. 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

o 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.

o Fixed with wakeup-waiting switch in condition variable (binary semaphore)


Compiler changes

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)


Performance issues

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


References

1. http://www.apearson.f2s.com/mesacourse10.html A website about the Mesa programming language, and its history.

2. “Monitors: An Operating System Structuring Concept” by C.A.R Hoare,The Queen's University of Belfast

3. “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

4. Duke University Systems and Architecture class slides

cs533 - concepts of operating systems 1 presentation summary of “experiences with processes and...

Documents

mesa monitors

operating systems

cs533 concepts

mesa programming language

systems software

development of pilot

new process

language construct slide