Monitors
- Monitors: An Operating System Structuring Concept
- Experience with Processes and Monitors in Mesa
Q: What are "monitor invariant" I and "condition" B, and why are they important in the discussion of monitors?
Q: Compare and contrast synchronization in Java with Hoare monitors and Mesa monitors.
Invariant & Condition
- I Invariant -> Lock
- B Condition -> The reason for waiting
The invariant can be assumed at the start of an entry procedure and after each WAIT. Under these conditions, the monitor lock ensures that no one can enter the monitor when the invariant is false.
Monitors in Hoare
I !B Wait B I
I B Signal I !B
IF <!B>
<...>
WAIT
Monitors in Mesa
I Wait I
B Signal (Notify) B
No context switch after signal, it will continue.
When Signal leaves monitor, wait may get the lock, but it is not guaranteed.
WHILE <!B>
<...>
WAIT
No tight coupling here.
Mesa's special thing
- Wait (Signal)
- Nested CALL
- Exception handling
- Dynamic Monitors
- Dynamic Processes
- Schedule -> Priority of monitors
- I/O Handling
Compare Hoare, Mesa, Java monitors
| Hoare | Mesa | Java | |
|---|---|---|---|
| Monitor Lock | ALL | Ext/Int Procedure | Every object is a monitor1 |
| Condition Vars | Yes | Yes* | Object |
| Wait | Yes | Yes* | Yes |
| Signal | Yes | Yes* -> BCAST | Yes notify(), notifyAll() |
| Granularity | Coarse | Per Instance | Yes2 |
| Aborts | No | Unwind handler, reestablish invariant | KILL, STOP3 |
| Nested calls | No | Yes4 | Yes5 |
1 More than half of the code implementing Object class is about synchronization.
2 There are two different types
- Synchronized block
- Class / Instance associated synchronization
3 KILL and STOP have already been deprecated in Java. Instead, a thread t0 set a variable to show the intention to kill another thread t1. t1 then does the clean-up and do the stop.
4 Programmer has to design the nested call in a correct way, to avoid incurring any deadlock.
5 Programmer needs to acquire locks in a partial order, ensure no circle dependency.