An Operating Systems Vade Mecum

Mechanisms 279(4) Let the programmer decide whether the nested call should maintain exclusion inthe old monitor or not. By default, method 1 is used. The programmer can sayduckout to release exclusion while still in the monitor and duckin to acquireexclusion again. These calls can bracket a nested call to simulate method 3.Although monitors represent a significant advance over the earlier devices we havestudied, they do have some significant problems. Monitors have been criticized for notproviding any control over how the queues are ordered. The policy to treat them in firstin,first-out order is not always appropriate. For example, several activities simultaneouslyin the urgent queue are like nested interrupts, which are usually released in first-in,last-out (stack) order. As another example, different waiters in a condition queue mayhave different priorities, which could be taken into account in selecting an order. Somepeople prefer a more general mechanism for inspecting and reordering the variousqueues.Monitors also display unexpected complexity with respect to nested calls. It is noteasy to describe the semantics of wait and signal without resorting to pictures like Figure8.3. Complexity is also introduced by the artificial use of condition variables. The programmeris more likely to understand the underlying condition (like ‘‘Count > 0’’) thanto represent that condition properly by judicious use of wait and signal.Another objection to monitors comes from their data-abstraction ability. If wehave several bounded buffers to implement, we would be tempted to build only one monitorand to have the PutBuffer and GetBuffer procedures take a parameter that describeswhich buffer is to be manipulated. This solution has two drawbacks. One is that thebuffer has an existence outside the monitor and so might be inadvertently modified by anon-monitor procedure. Luckily, modern programming languages have the idea of‘‘exported types’’ that exist outside a data-abstraction module but can be manipulatedonly from within that module. The other drawback is that using only one monitor is tooconservative: Every manipulation of one buffer now excludes operations on all otherbuffers because mutual exclusion is governed by which monitor is to be entered, not bywhich data structure is being accessed. Again, modern programming languages come tothe rescue. One can imagine a ‘‘monitor type’’ for bounded buffers. A new monitor ofthat type is built for each buffer needed. The program for monitors needs to be writtenonly once, but each buffer gets its own monitor with its own exclusion.A serious objection to monitors is related to our guideline that exclusion should notbe in force for very long. However, shared data might be needed for a very long time.This is exactly the situation in the readers-writers problem, mentioned in our chapter onfile structures.Readers-writers problemAny number of reader activities and writer activities are running. They sharesome data (for example, a file). At any time, a reader activity may wish to readdata from the file. At any time, a writer activity may want to read or modifythe data in the file. Reading and writing are time-consuming operations, butthey always finish eventually. During the time a writer is writing, no otherreader or writer may access the shared data. Any number of readers may accessthe data simultaneously. For fairness, we prefer that no reader or writer bestarved (that is, forced to wait indefinitely).If we make Read and Write guard procedures, two readers cannot execute at the same