Experience with Processes and Monitors in Mesa Lampson & Redell, Processes & 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 sbwood 2005

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

Concurrent Programming using Monitors 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

Signaling in Monitors J. H. Howard 2nd Intl. Conf Signaling in Monitors J. H. Howard 2nd 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 Problems SU & SW: signalers might wait & restart unnecessarily SR simplest but may be inadequate & SC complex sbwood 2005

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; Hoare semantic Mesa 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

Allocate: ENTRY PROCEDURE [size: INTEGER StorageAllocator: MONITOR = BEGIN availableStorage: INTEGER: moreAvailable: CONDITION: Allocate: ENTRY PROCEDURE [size: INTEGER RETURNS [p: POINTER] = BEGIN UNTIL availableStorage >= size DO WAIT moreAvailable 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>; NOTIFY moreAvailable 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

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

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

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

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

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

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

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

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 Mesa WHILE NOT <OK to proceed> DO WAIT c ENDLOOP Hoare IF NOT <OK to proceed> THEN WAIT c sbwood 2005

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

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

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

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

Lampson & Redell, Processes & Monitors in Mesa 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 sbwood 2005

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

Performance sbwood 2005

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

Closing comparison sbwood 2005

Implementation sbwood 2005

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