An Operating Systems Vade Mecum

278 Concurrency Chapter 8These rules assure that a waiting consumer is unblocked immediately when a producersignals NonEmpty and that the producer is blocked in the urgent queue until the consumerhas taken the datum. We have maintained our rule that at most one activity inhabitsthe central region.People who use monitors have noticed that the signal operation is almost alwaysthe last operation performed in a guard procedure. We see this behavior in ourproducer-consumer solution (lines 24 and 35). Our rules will often make the signalerwait in the urgent queue and then return to the central region just to get out of the monitoraltogether. This scenario violates the Hysteresis Principle. Furthermore, if the signalerdoes have more work to do, it can’t assume that the situation of shared variables is thesame when it returns from the urgent queue because the activity that was unblocked islikely to change them. For these reasons, some people require that signal must be the lastoperation of a guard procedure and must cause the signaling activity to leave the monitor.Then we don’t need an urgent queue, and signalers never make invalid assumptionsabout shared data. However, this restriction makes monitors less flexible. (Such monitorsare strictly less powerful in a theoretical sense.)A related suggestion is that broadcast should be like signal but should release allthe members of the associated condition queue. Since they can’t all be allowed into thecentral region at once, most are placed in the urgent queue. In this way, when conditionsare right, all the waiters may be released instead of the awkward alternative of havingeach released waiter releasing the next one in turn. However, a released activity can nolonger assume that the condition it has awaited is truly met by the time it resumes. Programswritten with broadcast usually replace the if statement in lines 29 through 31above with a while loop:29 while Count = 0 do30 wait NonEmpty;31 end;Proper use of monitors follows the guideline that no activity should take too longin the central region. It shouldn’t take too long for an activity that is waiting in the entryqueue to get into the monitor and access the shared variables. Any lengthy operationshould relax exclusion by entering a condition queue or by doing its work outside themonitor. A fascinating violation of this guideline arises if the activity in a guard proceduremakes a call on a guard procedure in another monitor. Under our rules, thisactivity is still considered to be in the first monitor, preventing any other activity fromentering. However, it may take a long time before it returns because it may be forced towait in the second monitor in a condition queue. (By our guideline, it shouldn’t have towait very long in either the entry queue or the urgent queue.) This delay in returningviolates our guideline with respect to the first monitor. It can even lead to deadlock if thecondition it awaits in the second monitor can be signaled only by an activity that iscurrently waiting patiently to enter the first monitor.A number of solutions to this problem have been proposed.(1) Warn the programmer but allow the bad situation to develop. That is, nestedmonitor calls maintain exclusion on the old monitor while in the new one.(2) Disallow nested monitor calls.(3) Release exclusion on the old monitor and enforce it only on the new one. Whenthe activity is ready to return, it must wait in the urgent queue of the first monitoruntil it can once again achieve exclusive use of the central region.