An Operating Systems Vade Mecum

272 Concurrency Chapter 8Variables are visible to more than one activity only if they are declared shared. Sharedvariables are invisible except within critical regions. Entry to critical regions automaticallyexcludes conflicting activities. Second, there is no way to forget to call Up at theend of a region. Up is no longer explicitly invoked.But several problems remain. The first is that synchronization requires busy waitingif critical regions are the only facility. The second is that accesses to shared variablesmay be scattered throughout the program, with the result that it is difficult to coordinateall the places that modify them. In addition, there is no way for several activities to readthe same shared variables simultaneously even though simultaneous reads need not bemutually exclusive. We will address these objections in the next few sections.2.8 Conditional critical regionsA slight modification to critical regions will allow us to solve the synchronization problemwithout busy wait. As we saw before, synchronization in general is the desire toblock an action until a particular condition becomes true. For example, the ‘‘pop’’operation makes sense only for a stack that is not empty. The action of popping the stackshould be delayed until that condition holds. Likewise, action B of Figure 8.1 shouldcontinue only if A has terminated.To meet these needs, we add an await statement that may only be used inside acritical region. Await names an arbitrary Boolean condition. If the condition is not met,the activity executing the await statement is blocked until it is met. For example, poppingfrom a stack could be done as follows:1 type2 stack =3 record4 Count : integer; { How many elements in stack }5 Values : array 1:10 of element;6 end;7 var8 Trays : shared stack;910 ...1112 region Trays do13 await Trays.Count > 0;14 Result := Trays.Values[Trays.Count];15 Trays.Count := Trays.Count - 1;16 end;To solve the synchronization problem of Figure 8.1, we can have a Boolean variableindicate when each activity finishes and test that variable in an await statement.We must decide exactly what the await statement means. Does it relax exclusionif it blocks? If not, how can another activity ever modify the condition that is beingawaited? If so, how can we be sure that no other activity has confused the data structureswhile we were blocked? One consistent approach is to demand that await statementsappear only at the start of critical regions and that exclusion not start until the condition ismet. (Of course, checking the condition must be atomic, a condition that can be achievedthrough hidden semaphores.) Another approach is to allow await statements anywhere