This preview shows pages 1–3. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: EWD 123 Cooperating sequential processes Table of Contents. Preface . 0. Introduction 1. On the Nature of Sequential Processes. 2. Loosely Connected Processes. 2.1. A Simple Example. 2.2. The Generalized Mutual Exclusion Problem . 2.3. A Linguistic Interlude . 3. The Mutual Exclusion Problem Revisited. 3.1. The Need for a More Realistic Solution. 3.2. The Synchronizing Primitives. 3.3. The Synchronizing Primitives Applied to the Mutual Exclusion Problem. 4. The General Semaphore. 4.1. Typical Uses of the General Semaphore. 4.2. The Superfluity of the General Semaphore. 4.3. The Bounded Buffer. 5. Cooperation via Status Variables. 5.1. An Example of a Priority Rule. 5.2. An Example of Conversations 5.2.1. Improvements of the Previous Program. 5.2.2. Proving the Correctness. 6. The Problem of the Deadly Embrace. 6.1. The Banker's Algorithm. 6.2. The Banker's Algorithm Applied 8/11/2010 E.W.Dijkstra Archive: Cooperating seq utexas.edu/users//EWD123-2.html 1/31 7. Concluding Remarks. 5. Cooperation via Status Variables . In sections 4.1 and 4.3 we have illustrated the use of the general semaphore. It proved an adequate tool, be it as implementation of a rather trivial form of interaction. The rules for the consumer are very simple: if there is something in the buffer, consume it. They are of the same simplicity as the behaviour rules of the wage earner who spends all his money as soon as he has been paid and is broke until the next pay day. In other words: when a group of cooperating sequential processes have to be constructed and the overall behaviour of these processes combined has to satisfy more elaborate requirements community, formed by them, has, as a whole, to be well-behaved in some sense we can only expect to be able to do so, if the individual processes themselves and the ways in which they can interact will get more refined. We can no longer expect a ready made solution as the general semaphore to do the job. In general, we need the flexibility as can be expressed in a program for a general purpose computer. We now have the raw material, we can define the individual processes, they can communicate with each other via the common variables and finally we have the synchronizing primitives. How we can compose from it what we might want is, however, by no means obvious. We must now train ourselves to use the tools, we must develop a style of programming, a style of "parallel programming" I might say. In advance I should like to stress two points. We shall be faced with a great amount of freedom. Interaction may imply decisions bearing upon more than one process and it is not always obvious, which of the processes should do it. If we cannot find a guiding priciple (e.g. efficiency considerations), then we must have the courage to impose some rule in the name of clarity....
View Full Document
- Spring '08
- Operating Systems