cs533 - concepts of operating systems 1 presentation summary of “experiences with processes and...
TRANSCRIPT
CS533 - Concepts of Operating Systems 1
Presentation Summary of “Experiences with Processes and Monitors in Mesa”
By Burke Ellett
CS533 - Concepts of Operating Systems 2
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
CS533 - Concepts of Operating Systems 3
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
CS533 - Concepts of Operating Systems 4
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.
CS533 - Concepts of Operating Systems 5
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.
CS533 - Concepts of Operating Systems 6
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)
CS533 - Concepts of Operating Systems 7
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.
CS533 - Concepts of Operating Systems 8
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
CS533 - Concepts of Operating Systems 9
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.
CS533 - Concepts of Operating Systems 10
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
CS533 - Concepts of Operating Systems 11
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)
CS533 - Concepts of Operating Systems 12
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
CS533 - Concepts of Operating Systems 13
Hoare Semantics for condition variable wakeup [4]
CS533 - Concepts of Operating Systems 14
Mesa Semantics for conditional variable wakeup [4]
CS533 - Concepts of Operating Systems 15
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
CS533 - Concepts of Operating Systems 16
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
CS533 - Concepts of Operating Systems 17
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.
CS533 - Concepts of Operating Systems 18
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)
CS533 - Concepts of Operating Systems 19
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)
CS533 - Concepts of Operating Systems 20
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
CS533 - Concepts of Operating Systems 21
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
CS533 - Concepts of Operating Systems 22
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
CS533 - Concepts of Operating Systems 23
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
CS533 - Concepts of Operating Systems 24
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