1 / 25

Experience with Processes and Monitors in Mesa

Experience with Processes and Monitors in Mesa. B. W. Lampson Xerox Palo Alto Research Center D. D. Redell Xerox Business Systems. Communications of the ACM v.23, n.2, Feb.1980, pp. 105-117. Design Goals. Local concurrent programming Global resource sharing Replacing interrupts.

muniya
Download Presentation

Experience with Processes and Monitors in Mesa

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Experience with Processes and Monitors in Mesa B. W. Lampson Xerox Palo Alto Research Center D. D. Redell Xerox Business Systems Communications of the ACM v.23, n.2, Feb.1980, pp. 105-117

  2. Design Goals • Local concurrent programming • Global resource sharing • Replacing interrupts sbwood 2005

  3. Concurrent Programming usingMonitors in Mesa • Interactions with process creation and destruction • How to define WAIT • Priority scheduling • Semantics of nested monitor calls • Handling timeouts, aborts, and other exceptions • Monitoring large numbers of small objects sbwood 2005

  4. Signaling in MonitorsJ. H. Howard2nd Intl. Conf. of Software Engr, Oct.1976 • SU signal & urgent wait Hoare’74 • signaler to “urgent” queue & resumes after • signaled process runs • SR signal & return Brinch Hansen’75 • return from monitor immediately after signaling • Concurrent PASCAL • SW signal & wait Howard’76 • signaled immediate access • signaler to monitor’s entry queue • SC signal & continue • signaler’s view of monitor state not corrupted • requires explicit recording of signals pending ProblemsSU & SW: signalers might wait & restart unnecessarily SR simplest but may be inadequate & SC complex sbwood 2005

  5. Excerpt of Tanenbaum’s Example of Hoare Semantic Monitor ProducerConsumer condition full, empty; integer count; procedure insert (item; integer); begin Modification for Mesa Semantic if count = N then wait (full); while not count = N do wait (full) insert_item (item); count := count + 1; if count = 1 then signal (empty); end; Mesa semantic Hoare semantic Signaling thread suspends on urgent Signaled thread wakes & runs immediately First thread regains possession of monitor when second completes Signaling thread continues Signaled thread rechecks condition because order not guaranteed Avoid context switch sbwood 2005

  6. StorageAllocator: MONITOR = BEGIN availableStorage: INTEGER: moreAvailable: CONDITION: Allocate: ENTRY PROCEDURE [size: INTEGER RETURNS [p: POINTER] = BEGIN UNTIL availableStorage >= size DO WAITmoreAvailable ENDLOOP; p <- <remove chunk of size words & update availableStorage> END; Free: ENTRY PROCEDURE [p: POINTER, Size: INTEGER] = BEGIN <put back chunk of size words & update availableStorage>; NOTIFYmoreAvailable END; Expand:PUBLIC PROCEDURE [pOld: POINTER, size: INTEGER] RETURNS [pNew: POINTER] = BEGIN pNew <- Allocate[size]; <copy contents from old block to new block>; Free[pOld] END; END. sbwood 2005

  7. Mutual exclusion • Asynchronous processes must not Allocate and Free simultaneously → use entry procedures • Monitor lock not needed during copy in Expand → use external procedure • Structure the monitor computations only when lock is already held → use internal procedure sbwood 2005

  8. Define WAIT • If caller waits in entry procedure, it releases the lock • If wait in internal procedure, the lock is released • If monitor calls procedure outside the monitor, the lock is not released sbwood 2005

  9. Invariant • Always true, except when process is executing in the monitor • On entry, invariant assumed to hold • Invariant established before control leaves monitor • Monitor procedure must establish invariant before WAIT • Consider exception handler called from entry procedure sbwood 2005

  10. Causes ofPair-wise Deadlock • 2 processes WAIT in a single monitor • Cyclic calling between 2 monitors → impose a partial order • Two level data abstraction sbwood 2005

  11. Two level data abstraction Example: Monitor M calls N and waits for C requires process to enter N through M to set C → DEADLOCK Divide M into monitor M’ and interface O to call N sbwood 2005

  12. Monitored Objects • Collection of shared data objects • Multiple instances of monitor • Duplication of program linking and code swapping • Monitored record • To access a file, pass as parameter to effectively create a separate monitor for each object (read-only, no aliasing) sbwood 2005

  13. Abandon computation • UNWIND exception to allow clean-up by any active procedure • If procedure to be abandoned is an entry procedure, must restore invariant and release lock • Programmer provides handler or experiences deadlock • Compare to Java exception handling sbwood 2005

  14. Condition variables • Process establishes a condition for which another process waits • NOTIFY is a hint that waiting process will resume and reacquire the monitor lock • No guarantee about another process interceding • Waiter must reevaluate when it resumes MesaWHILE NOT <OK to proceed> DO WAIT c ENDLOOP Hoare IF NOT <OK to proceed>THEN WAIT c sbwood 2005

  15. Verification rules • Simpler and more localized • Invariant established before return from entry procedure or a WAIT • Invariant assumed at start of entry procedure and just after a WAIT • Waiter explicitly tests • Notify condition may be more general (low cost to wake a process) sbwood 2005

  16. NOTIFY alternatives • Timeout with interval • Abort • Broadcast • I/O device communication • device cannot wait on monitor lock • notify condition variable to wake interrupt handler sbwood 2005

  17. Priorities • Ordering implied by assignment of priorities can be subverted by monitors • Associate with each monitor the priority of the highest priority process that ever enters the monitor(Modula disables interrupts, but this fails with page fault.) sbwood 2005

  18. Example of subverted priority Process P1 enters monitor M, P2 preempts, P3 preempts P3 tries to enter monitor and waits for lock P1 enter M P2 preempt P1 P3 preempt P2 P2 runs again, effectively keeps P3 from running, undermining the priorities. sbwood 2005

  19. Processor Process states (pcbs) in queues sorted by priority • Ready queue • Monitor lock queue • Condition variable queue • Fault queue Queue cell process state process state process state ---- head tail sbwood 2005

  20. Implementation • Compiler – flags errors • WAIT in external procedure • direct call from external to internal procedure • Runtime – process creation and destruction • Machine – process scheduling and monitor entry/exit sbwood 2005

  21. Performance sbwood 2005

  22. Validation of Mesa Semantic • Operating system • Interrupt handling lack of mutual exclusion • Interaction of concurrency and exception • Database • Single monitor and single condition variable • Array of representative states • Network communication • Router monitor • Network driver monitor sbwood 2005

  23. Closing comparison sbwood 2005

  24. Implementation sbwood 2005

  25. Questions • Monitor – low level mechanism • Starvation addressed by high level scheduling • Simpler & localized verification rules • Signaled process checks specific condition • More general condition for notify • Should signal be the last operation of a • monitor procedure? • How is exception handling addressed? sbwood 2005

More Related