1. 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
sbwood 2005

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

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

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

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;
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

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

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

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
Mesa WHILE 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. 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

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