13.07.2015 Views

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

An Operating Systems Vade Mecum

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

290 Concurrency Chapter 8The parameters to the operation: The data that are being put in the buffer do notinfluence our solution, but we could imagine that some data are more crucial thanothers.The identity of the caller: We would not like a producer to call GetBuffer.Path expressions ignore the data state of the resource, the parameters to the operation,and the identity of the caller. Invariant expressions concentrate heavily on the history ofaccesses, expressing other items of interest (like the synchronization state and the datastate) in terms of that history.Ease of use is a subjective criterion. Conditional critical regions are much easier touse than monitors, but they are not in as widespread use. Invariant expressions seemmore usable than path expressions in the examples we have seen.The choice of mechanisms for concurrency control depends on efficiency and onintended use. Inside the operating system kernel, it often suffices to use the simplest lockbased on raising priority for short access to shared data; longer accesses that mightinvolve synchronization considerations (like placing data in a buffer) would have to use amore expensive solution. If processes, which are outside the kernel, need to share data,the kernel might give them a semaphore facility through service calls. This facility mightthen be used to construct monitors or event counts.The programming language chosen by the operating system writer has an obviousinfluence on the solutions chosen for the kernel. For example, an operating system writtenin Modula or Concurrent Pascal is likely to use the monitor-like concepts in thoselanguages. Similarly, the facilities offered by the operating system have an influence onconcurrency control between processes that share data (either virtual store or files).4 FURTHER READINGMost of our understanding of concurrency control is due to the early work of a fewgiants: Dijkstra, Hoare, and Brinch Hansen. T. J. Dekker introduced the non-alternatingswitch in the early 1960s. This concept was generalized by Dijkstra (1965) to make thespin switch. Peterson (1981) simplified the non-alternating switch. Monitors werealready in the works when conditional critical regions were designed. Hoare (1972) firstmentioned conditional critical regions, and Brinch Hansen (1980) later used them as theprincipal mechanism for concurrency control in his language, Edison. Dijkstra (1971)introduced the notion of a ‘‘secretary,’’ the forerunner of the modern monitor, at thesame time conditional critical regions were introduced by Hoare. Dijkstra’s paper isworth reading for his insight into the mutual-exclusion and synchronization problems andhis foresight of problems such as the nested monitor call. The term ‘‘monitor’’ wasintroduced by Hoare (1974). Nested monitor calls have been discussed at length in theliterature; one place to find more discussion on this topic is in a paper by Haddon (1977).Howard (1976) has shown that monitors with signal only at the end are strictly lesspowerful than ordinary monitors. The broadcast version of signal has been used successfullyin Mesa (Lampson and Redell, 1980). Crowds are based on serializers, whichwere introduced by Atkinson and Hewitt (1979) and generalized by Horn and Honda

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!