32.ppt
Upcoming SlideShare
Loading in...5
×
 

32.ppt

on

  • 424 views

 

Statistics

Views

Total Views
424
Views on SlideShare
424
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

32.ppt 32.ppt Presentation Transcript

  • 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 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
    • 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
      • 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)
    • -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
      • 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
        • 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 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)
  • 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
    • 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