Download Communicating Sequential Processes
Transcript
6.3 Shared storage 187 cover the danger zone, and so remove the concavity. One technique would be to introduce an additional artificial resource which must be acquired before either utensil,and must not be released until both utensils have been released. This solution is similar to the one imposed by the footman in the story of the dining philosophers (Section 2.5.3) where permission to sit down is a kind of resource, of which only four instances are shared among five philosophers. An easier solution is to insist that any cook who is going to want both utensils must acquire the pan first. This example is due to E. W. Dijkstra. The easier solution suggested for the previous example generalises to any number of users, and any number of resources. Provided that there is a fixed order in which all users acquire the resources they want, there is no risk of deadlock. Users should release the resources as soon as they have finished with them; the order of release does not matter. Users may even acquire resources out of order, provided that at the time of acquisition they have already released all resources which are later in the standard ordering. Observance of this discipline of resource acquisition and release can often be checked by a visual scan of the text of the user processes. 6.3 Shared storage The purpose of this section is to argue against the use of shared storage; the section may be omitted by those who are already convinced. The behaviour of systems of concurrent processes can readily be implemented on a single conventional stored program computer, by a technique known as timesharing, in which a single processor executes each of the processes in alternation, with process change on occurrence of interrupt from an external device or from a regular timer. In this implementation, it is very easy to allow the concurrent processes to share locations of common storage, which are accessed and assigned simply by means of the usual machine instructions within the code for each of the processes. A location of shared storage can be modelled in our theory as a shared variable (4.2 X7) with the appropriate symbolic name, for example (count : VAR // (count .left !0 → (P ||| Q ))) Shared storage must be clearly distinguished from the local storage described in 5.5. The simplicity of the laws for reasoning about sequential processes derives solely from the fact that each variable is updated by at most one process; and these laws do not deal with the many dangers that arise from arbitrary interleaving of assignments from different processes. These dangers are most clearly illustrated by the following example.