Why was the definition of monitors and condition variables changed in
the Mesa implementation from that described by Hoare? What are the implications
of these changes?
The reason to change the definition of monitors and conditions variables in Mesa implementation from that descried by Hoare is that Mesa was designed to support the large size and wide variety of applications which involves very complicated concurrency control, and monitors had to be refined sufficiently to fit into this context.
In Mesa a monitor is an instance of module, which has three kinds of procedures: entry, internal and external. In Hoare's paper, a monitor only has entry procedures. Therefore, Mesa provides more flexible operations on monitor. For example, a process can change a monitor's local variables outside a monitor via external procedures, or structure its computations in the monitor without acquire and release the lock on call and return via internal procedures.
In Mesa a monitored record is used to create an individual monitor for
each object to obtain the maximum concurrency, at the same time the cost
in duplicating some information in the multiple instances of the monitor
module which uses to support program linking and code swapping is avoided,
and the program can exercise the fine control over allocation strategies
on
module instances.
In Mesa UNWIND exception is provided to release the monitor lock held by an entry procedure if it is abandoned before finishing. Hoare doesn't describe the mechanism to deal with this situation.
Hoare's definition of monitors requires that a process waiting on a condition variable must run immediately when another process signals that variable, and that the signaling process in turn runs as soon as the waiter leaves the monitor. But, in Mesa when one process establishes a condition for which some other process may be waiting, it notifies the corresponding condition variable. This change has the following implications:
1. Hoare's definition requires several additional process switches whenever
a process continues after a wait. Mesa avoids this
cost and no constraints at all on when the waiting process must
run after a NOTIFY, although it results in an extra evaluation of the predicate
after a wait. The possible unfairness and starvation on monitor
access scheduling in Mesa is avoided
by high level scheduling.
2. The verification rules for Mesa monitors are extremely simple and more localized.
3.Mesa separates the NOTIFY and the exact condition checking. Any change on the condition will be notified to a covering condition variable, and then it is the waiting process' responsible to determine whether the exact condition holds. Therefore, the detailed design of two processes can be decoupled.
4. In addition to notify, there are three ways to resume a waiting process: timeout, about, broadcast.
5. In Mesa communication with input/output devices is handled by monitors and condition variables, in which devices would wait on and acquire the monitor lock, exactly like ordinary Mesa processes. In addition, any mutual exclusion between Mesa code and device hardware and microcode are tried to avoid to get better worst-case real time performance.
The final monitor refinement in Mesa is that it associates with each
monitor the priority of the highest priority process which ever enters
that monitor to ensure the CPU priority scheduling discipline imposed by
some application.