An Operating Systems Vade Mecum

Perspective 2893 PERSPECTIVEIt is necessary to distinguish carefully between simple mutual-exclusion situations, whereit is dangerous for two activities both to proceed, and synchronization situations, wherecomplex conditions might govern when an activity may proceed. To show pure forms ofboth situations, we considered modifying shared data (pure mutual exclusion) and Figure8.1 (pure synchronization). Later, we turned to the producer-consumer problem and thereaders-writers problem as more complex examples. These latter examples displayaspects both of mutual exclusion (we don’t want two producers simultaneously writinginto the buffer, and we don’t want two writers simultaneously active) and of synchronization(consumers must wait until data are produced; readers should wait if there are waitingwriters). The situations that occur within operating systems are typically of thishybrid variety.The methods we have seen range from simple hardware techniques toprogramming-language constructs that try to guarantee that the restrictions described areclear, efficiently implementable, and unlikely to be misused. The more complex solutionsare invariably implemented by behind-the-scenes work using a simpler solution.For example, monitors can be implemented by semaphores. Semaphores themselvesneed to turn on mutual exclusion around critical parts of their implementation, and mightdo that with test-and-set locks. At the bottom of this ladder always stands the inherentatomicity of main store, which serves only one access at a time.One might evaluate different proposals on the basis of three characteristics: modularity,expressive power, and ease of use. Modularity is achieved by data abstraction andby separating concurrency control from resource access. Monitors, crowd monitors, pathexpressions, and invariant expressions all display a high degree of modularity.Expressive power involves ability to formulate exclusion, synchronization, andpriority requirements. Each of the methods displayed is capable of formulating the firsttwo kinds of requirement. None does well with respect to priority because queues arebuilt into most of the methods without any mechanism for inspecting and reorderingthose queues.Requirements may depend on a host of criteria. A partial list follows. For each,we show how it applies to the producers-consumers problem.What operation is being requested: PutBuffer and GetBuffer have different requirements.When the request is made: If two activities call PutBuffer, the one that called firstshould take precedence (in the absence of priority).The synchronization state of the resource: The fact that an activity is currently executingGetBuffer implies that another activity should be delayed in executing thesame procedure.The data state of the resource: GetBuffer is blocked if the buffer is empty.The history of accesses: We block PutBuffer if there haven’t been enough calls toGetBuffer. We could pose this same constraint as part of the data state of theresource.