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.