An Operating Systems Vade Mecum

Mechanisms 273in the critical region. Any await that blocks releases exclusion, so it is up to the programmerto make sure that data structures are consistent before encountering await. Inthis way other activities will not be confused when they enter their conflicting region, andthe blocked activity will not be confused when it resumes.We must also decide exactly when the conditions are to be tested. If each activityis on a separate processor, we may test conditions continually. However, since such busywaiting is unacceptable for most implementations, we need to limit the times when thecondition may be tested. Certainly there is no need to test the condition as long as someother activity is in a conflicting region, because that other activity must maintain exclusionuntil it leaves its region, even though it may have made the condition true by itsactions. In practice, there may be no need to test conditions when all activities are outsideconflicting regions because useful conditions involve shared variables, and sharedvariables are changed only by activities within critical regions. One time we need tocheck conditions is when an activity leaves a critical region; the only conditions that mustbe tested are those in conflicting regions. The other time is when an activity in aconflicting region enters await. (This situation only arises if await is permitted in themiddle of regions.) Checking a condition can still be very expensive because it mayrequire switching to the environment of the blocked activity in order to access local variablesinvolved in the condition. For efficiency, such complex conditions may be disallowed.To show how conditional critical regions can be used to implement our synchronizationgraph, we present the code for activity E:1 var2 ADone, BDone, CDone, DDone, EDone, FDone, GDone :3 shared Boolean := false;45 activity E:6 region BDone do await BDone end;7 region DDone do await DDone end;8 perform E’s work;9 region EDone do EDone := true; end;Conditional critical regions are very easy to use for complex mutual-exclusion and synchronizationproblems. The exercises at the end of this chapter suggest some problems totry; they are based on ideas we will introduce soon.2.9 MonitorsOne objection to using conditional critical regions is the cost involved in checking conditions.A second objection is that code that modifies shared data may be scatteredthroughout a program. The language construct called a monitor was invented to addressboth these issues. It acts both as a data-abstraction device and a mutual-exclusion device.Synchronization is provided by a new data type called a condition.A data-abstraction device is a programming construct that separates operationson data from their implementation details, thus providing new function while hidingunnecessary structure. (We have seen abstraction as a form of the Beautification Principle.)In languages that provide such devices, they usually have the form of a new name