One-line summary: There are many practical issues associated with monitors that are not dealt with in the textbook descriptions - these issues are described in this paper.
The problem is to design a concurrency facility suitable for a large OS, enabling resource sharing, mutual exclusion, multiprocessing, etc. It should also fit naturally into the Mesa program language (modules, threads, exception handlers).
Implied functionality for monitors includes dynamic monitor creation, nesting of monitor waits and calls, "unwind" within monitors, and correct scheduling.
Stated without proof that monitors and message passing are equivalently powerful. (Can implement one with the other.)
Hoare's definition of monitors: code, data, and condition variables
colocated in a monitor. Monitor consists of entry procedures, internal
procedures, and external procedures. Serialization done on access to
monitor procedures (entry + internal).
wait operations: signal immediately relinquishes control to one
wait, and regains control once that wait leaves the monitor (many context
Monitors don't solve all concurrency problems - allowable ordering of entry procedure calls must be determined and enforced externally to the mechanism (eg tape drive operations).
wait will clear the monitor lock, even if done inside an
internal procedure. The monitor lock is not cleared when an external procedure
is called. This ensures that the monitor invariant is mantained whenever the
lock is not set: invariant must be established before lock is released.
Three pairwise deadlocks:
Problem: what if we have many instances of a class of object, and want to associate monitors with each instance instead of one for the class? Solution: well, do just that - condition variable per object (inside a structure, potentially). Condition variable must be reachable by monitor procedure (argument to monitor procedures as one way to do this).
Benefits: less context switching, no constraints on when process must run after notify, semantically correct to awaken waiters at random times(!), do notify on a generic condition variable rather than associating more context with many specific condition variables. Drawbacks: what about starvation and unfairness?
implementation split between hardware, compiler, and runtime.
4 process queues: ready, monitor lock. condition variable, fault.
No memory protection in Mesa: language/compiler strong enough.
monitor call roughly 2 times as long as procedure call.
inexpensive context switch (good for broadcasts).
Pilot OS: I/O interrupts done as naked notifies. Lack of mutexes in interupt handling. Bad interactions between concurrency and exception facilities. (
unwinds in entry procedures due to
some fluffy applications.