Experiences and Processes and Monitors with Mesa

1. What is Mesa? “Mesa is a strongly typed, block structured programming language whose syntax is similar to that of Pascal. “ [1] Besides being a language, it is essentially a scheduler for resources with one monitor per resource. Design Goals of Mesa Develop a model for controlling concurrency using monitors for: 1) local concurrent programming 2) global resource sharing 3) replace use of interrupts Experiences and Processes and Monitors with Mesa

2. Other options for concurrency • Considered but rejected: • Message passing • deemed to be equal to monitors but the message passing would require more work to develop a message-passing scheme • Shared memory • It would not work on multiple processors • Needed an additional preemptive mechanism (ie interrupts • Would need mutex • If didn't use mutex, needed sempahore

3. Mesa Monitor Review • Has procedures and global data • Entry procedure(s) for asynchronous access • To gain access to the critical section • Must hold the lock • Called from outside the monitor • Internal procedure(s) • Must hold the lock • Is private • Called from inside the monitor • External procedure(s) (Hoare does not have) • Non-monitor activity (not in critical section) • Global data – not seen outside the monitor • global to the critical section but still private data

4. Problems Addressed by Mesa • Not handled by other monitor papers 1. Dynamic process creation and destruction 2. Semantics of nested monitor calls 3. Defining the meaning of WAIT 4. Priority scheduling 5. Exception handling (e.g. aborts, timeouts) 6. Monitoring large numbers of small objects 7. I/O

5. 1. Dynamic Creation of processes in Mesa • New process is invoked concurrently with its caller (can be detached) • Communicate with a process the same way you communicate with a procedure • Can call with parameters • Can return a value • Subject to strict type checking • No special declaration for a procedure that is invoked by a process • Cost of creating/destroying is moderate (why?) • Allows interprocess communication without much overhead.

6. 2. Patterns of Deadlocks • Single process deadlocks with self (recursive) • Avoid recursive entry procedures • 2 processes end up in WAIT, each waiting for the other to wake it up • Typically a bug that needs to be corrected • Cyclic dependency among monitors • Impose partial ordering • Order dependent • Break monitors into smaller parts

7. 3. WAIT defined • If a caller has to wait in an entry procedure, • It signals with a Notify • It releases the lock (waiting process will need to reacquire it when it enters the monitor) • If wait is in one of the internal procedures, the lock is released • If a monitor calls an external procedure, the lock is NOT acquired or released because the lock is already held

8. 3. WAIT continued • Mesa WHILE NOT <OK to proceed> DO WAIT c ENDLOOP Results in an extra evaluation of the condition but there are no extra process switches and no constraints on when the waiting process can run after a notify • Hoare IF NOT <OK to proceed> THEN WAIT c

9. 3. WAIT summary • Mesa: a monitor that is in a WAIT releases the lock. • When control leaves the monitor, the invariant must be established: • before returning • before doing a WAIT • Whenever control enters the monitor, the invariant can be assumed. • At the start of an entry procedure • after a WAIT

10. Conditions • Condition.wait • Release monitor lock • Put process to sleep. • When process wakes up again, re-acquire monitor lock immediately. • Condition.notify • Wake up (at some time in the future) some process waiting on the condition variable (queue). • Hoare's definition a process must run immediately • If nobody waiting, do nothing. Signal is lost. • Condition.broadcast • Wake all processes waiting on the condition variable (queue) • If nobody waiting, do nothing. Signal is lost.

11. Notify • For resuming waiting processes • Really only a hint • Signaler continues vs signal yields (Hoare) • Alternatives to attract the attention of a waiting process • Timeout • Abort • Broadcast

12. 4. Priority Scheduling • Hoare's method allows more “senior” threads to obtain the lock • Mesa does not so it has to have a way to ensure starvation does not occur • Associate with each monitor the priority of the highest priority process which never enters a monitor. Then when a process enters a monitor, its priority is temporarily increased.

13. 5. Exception Handling • UNWIND • Uses the procedure call process to control the processing of exceptions – they either run concurrently or are separate processes (becomes the root process that must deal with an exception if it occurs)

14. 6. Monitored Shared Data Objects • Examples: file, database, external storage • Want to be able to add and remove shared data objects as needed • Access needs to be serializable • To accomplish • Single monitor per object • Multiple monitor instances per object • <Some option I don't understand fully yet> • Monitored record • Programmer specifies how to access the monitored record but Mesa's type system does not support this well

15. 7. I/O Handling • Problem: Devices cannot wait on a monitor lock • Solution: a notify that does not acquire a lock • A naked notify is a notify that causes an interrupt handler to take over so the actions can be atomic.

16. Summary/Conclusion • Hoare monitor construct: entry and internal procedures • Mesa: entry, internal and external procedures • Hoare monitor • Fixed number of monitors • Does not handle excpetions • Mesa • Dynamic number of monitors - can grow and shrink as necessary • A monitor can have an exception handler associated with it • Can create dangling processes (can be a monitor)

17. Summary/Conclusion • Hoare monitor • a waiting process can run when another monitor signals that variable • signalling process runs as soon as the waiter leaves the monitors (the signaling thread yields.) • the wait checks the invariant once (in an if statement) because it assumes the lock still holds • Mesa monitor • waiting process has to check condition to resume because notify makes no guarantee of condition • the released thread yields the monitor • notify thread retains the lock and continues • The wait has to be checked in a loop

18. References • [1]http://www.apearson.f2s.com/mesacourse1.html • [2] http://docs.sun.com/app/docs/doc/816-5137/6mba5vpl1?a=view • http://www.cis.temple.edu/~ingargio/old/cis307s95/readings/monitor.html • Modern Operating Systems 2nd edition, Andrew S. Tanenbaum • http://msdn2. • microsoft.com/en-US/library/ms228964%28VS.80%29.aspx • http://www.cs.mtu.edu/%7Eshene/NSF-3/e-Book/MONITOR/monitor-types.html

19. Invariant process:Conditions & Locks “An invariant is a condition or relation that is true when the associated lock is being set. Once the lock is set, the invariant can be false. However, the code that holds the lock must reestablish the invariant before releasing the lock.” [2]