Some Deadlock Properties of Computer Systems

Some Deadlock Properties of Computer SystemsRICHARD C. HOLTUnwers~ty of Toronto,*Toronlo, Onlarzo, CanadaSeveral examples of deadlock occurring in present day computer systems aregiven Next, there is a discussion of the strategms which can be ~sed to dealwith the deadlock problem A theory of computer systems is developed so thatthe terms "process" and "deadlock" can be defined. "Reusable resources" areintroduced to model objects that are shared among processes, and "consumableresources" are introduced to model signals or messages passed among processes. Thena rumple graph model of computer systems m developed, and its deadlock propertmsare investigated This graph model unifies a number of previous results, leads toefficient deadlock detection and prevenUon algorithms, and ~s useful for teachingpurposes.Key words and phrases: deadlock, deadly embrace, knot, interlock, pre-empuon,resource allocation, operating system, graph reductionCR categorzes: 4 31, 4.321. COMPUTER SYSTEMS AND DEADLOCKIn this paper we present a simple graphmodel of computer systems and investigateits deadlock properties. This model unifies anumber of previous results, leads to efficientdeadlock detection and prevention algorithms,and is useful for teaching purposes.Deadlock is the situation in which one ormore processes in a system are blocked foreverbecause of requirements that can neverbe satisfied. That is, deadlocked processes willremain blocked until special action is takenby some "external force" such as the operatoror the operating system.Let us consider a simple example of deadlockwhich can occur when there are twoprocesses, P1 and P2, and two resources, R1and R2. Assume that a resource cannot bereleased by (or pre-empted from) a processwaiting for a request. Suppose R1 has beenassigned to P1, and R2 has been assigned toP2. Now suppose P1 requests R2 and, P2requests R1. The result is that P1 and P2are deadlocked.*Department of Computer Scmnce and ComputerSystems Research Group.To a large extent, studying deadlockmeans studying the logic of process interactionsin computer systems. At present, ourability to build large, reliable computersystems is something less than satisfactory;this situation can be attributed to our lackof understanding of how the integral partsof such systems interact. Examples of interactionsamong processes leading to systemfailure from deadlock have been describedby various authors [9, 11, 13, 21]. It is hopedthat this paper will make the problem ofdeadlock easier to understand and analyze,thereby improving our ability to build reliablecomputer systems.This paper is organized in the followingfashion. Section 2 gives examples of deadlockin present day computer systems. This isfollowed by a listing of the methods availablefor handling the deadlock problem. InSection 4 we present a theory of computersystems so that terms such as "process"and "deadlock" can be defined. Then, "reusableresources" are introduced to modelphysical objects (or objects behaving likephysical objects) which are shared by proc-Computing Storeys, Vol 4, No. 3, September 1972

180 • R. C. HoltCONTENTS1 Computer Systems and Deadlock 179-1802 Examples of Deadlock m Current Systems 180-1813 Deadlock Strategies 181-1824. Basra Defimtlons 182-1835 An Example of a Simple System 1836 Resources m Computer Systems 183-1857 Some Defimtlons from Graph Theory 185-1868 General Resource Systems 186-1889. Necessary and Sufficmnt Condltmns for Deadlock188-19010 General Resource Systems with Single UmtRequests 190-192ll Consumable Resource Systems 192-19312. Deadlock Detection in Reusable Resource Systems193-19413. Deadlock Prevention in Reusable ResourceSystems 194-19514 Conclusion 195References 195-196Copyright © 1971, Association for ComputingMachinery, Inc General permission to republish,but not for profit, all or part of this material isgranted, provided that reference is made to thinpublicatmn, to ~ts date of issue, and to the factthat reprinting prtvdeges were granted by permissionof the Association for Computing Machinery.esses, and "consumable resources" are introducedto model messages or signals ,passedamong processes. Section 8 presents a simplegraph model of processes interacting viareusable and consumable resources. This isfollowed by development of necessary andsufficient conditions for detection and preventionof deadlock for various special casesof the general model. Using these conditions,efficient algorithms are developed for thedetection and prevention of deadlock.2. EXAMPLES OF DEADLOCK IN CURRENTSYSTEMSOne of the major advantages provided byoperating systems is the ability to shareresources among processes. Whenever resourcescan be requested and held by processes,deadlock is a potential problem; thus,the operating system designer should be wellacquainted with solutions to this problem.One might argue that deadlock is of littleinterest in current operating systems, andthat the problem is apparently solved becauseit is seldom observed. It is true thatdeadlock caused by competition for devices,such as tape and disk drives, has been preventedby effective ad hoc procedures. (See[9] for a discussion of such procedures usedin OS/360.) However, it is not at all obviousthat these ad hoc methods are optimal;further work is required to clarify exactlywhat methods are possible and which are theleast costly.In spooling systems, such as ASP/OS/360[16], deadlock sometimes occurs because ofcompetition for spooling space on the disk.The problem arises when the spooling spacebecomes completely filled with input recordsfor jobs waiting to execute and with outputrecords for jobs not finished executing. Thereis no way to recover the spooling spaceoccupied by a partially executed job (atleast not in ASP/OS/360); the only way torecover from such a deadlock is to restartthe system. The somewhat crude ad hocsolution to this problem is to prohibit (manually)the spooling of new jobs once theutilization of spooling space becomes toohigh, say above 80 % utilization. It is obvi-Computing Storeys, Vol 4, No 3, September 1972

182 • R. C. Holtbit too unkind because this strategy savesthe time and space required by deadlockprevention and detection algorithms.The methods of handling the deadlockproblem which are discussed below areexamples of prevention and detection strategies.4. BASIC DEFINITIONSIn order to investigate the problem of deadlock,we need to understand exactly what ismeant by the terms "system" and "process."We define a system as a pair (Z, H) whereis a set of states { 3, T, U, V, W, ... }, andII is a set of processes {P1, P2, P3,... }.(We do not insist that ~ and 1I be finitesets. In the system introduced in Section 8,is infinite and H is finite.) Each process P,is defined as a mapping from the systemstates into the subsets of system states.Figure 1 illustrates a system whose statesare {3, T, U, V} and whose processes are{P1, P21 . In this system, process P1 mapsstate 3 into {T, U}. We may interpret thisto mean that when the system is in state S,process P1 may change the state to eitherTor U.If process P, maps state S into a subset ofcontaining state T, then we write1Fro. 1 Example of a system m which process P2can deadlock. The set of states is ~ --~ [S,T,U,V}. and the set of processes is II ~-- [P1, /)2} .3 $ ) T.(Read "process P~ takes 3 to T.") We callthe change of state from S to T an operationby process P,. Operations in Figure I includethe following: S 1 T, S 1 U, T 1 3,T 2 S, T 2 V. If the system allows thefollowing sequence of zero or more changesof state:S-~T,T~we write3 .... )W.U,...,V--X W, thenFor example, in Figure 1, 3 1 T and T 2 V;$thus, 3 --~ V.The notion of "processes" in computersystems is well known [5, 12, 18, 23]. Ourdefinition is noteworthy for two reasons.First, the definition is simple and precise,yet convenient for our purposes. Second, ourdefinition allows processes to be nondeterministic;for example, in Figure 1 process P1can change state 3 to either T or U. We mayinterpret this nondeterminism to mean thatwe may not be able to know (or may noteven wish to know) exactly what each processwill do next. For example, we may knowthat process P2 is presently capable of eitherrequesting resource R1 or releasing resourceR2, but we may not know which operationP2 will actually execute.When process P, can execute no operation,we say P, is blocked; if P, will never againbe able to execute an operation, we say P, isdeadlocked. Formally:Process P, is blocked in state 3 if thereexists no state T such that 3 / T.Process P~ is deadlocked in state 3 if forall T such that S --~ T, P, is blocked inT.In Figure 1 process P2 is blocked (but notdeadlocked) in state 3, and process P2 isdeadlocked in states U and V.From these definitions it follows thatprocess P, is not deadlocked in state 3 if and$only if there exists T such that S -~ T andprocess P, is not blocked in T.If one or more processes are deadlocked inComputing Surveys, Vol 4, No. 3, September 1972

Some Deadlock Properties of Computer Systems • 183state S, then we say S is a deadlock state. Ifall processes are deadlocked in S, we say Sis a total deadlock state. In Figure 1, U andV are deadlock states, but there are no totaldeadlock states.We shall say that a state is secure if itcannot change (in any number of operations)to become a deadlock state. That is:State S is secure if for all T such thatS -* T, T is not a deadlock state.We shall say a system is secure if it containsone or more secure states.The lemma given below follows immediatelyfrom the preceding definitions.Suppose S --~ T. If S is a deadlock state,then T is a deadlock state. If S is asecure state, then T is a secure state.Thus, deadlock and security are "perma_nent" conditions.The definitions given in this section canbe applied in various situations; for example,a process might be a production in a contextfreegrammar, or a set of transitions in aPetri net [10], or a chessman on a chessboard,or a vector in a vector addition system [17].In the following sections, we shall applythese definitions to models of computersystems.5. AN EXAMPLE OF A SIMPLE SYSTEMWe shall now show how these definitionscan be used in a system consisting of twoprocesses that share two identical units of aresource. Assume that each process is able torequest only one unit of the resource at atime, and that a process holding units canrelease only one unit at a time. In this system,each process is in one of the followingstates:0) The process holds no units and has requestedno units.1) The process holds no units and has requestedone unit.2) The process holds one unit and has requestedno units.3) The process holds one unit and has requestedone unit.4) The process holds two units and has requestedno units.(We can assume a process will not requestanother unit when it holds two units, becausethere is a total of two units.) A processcan change states from 0 to 1 by requestinga unit, from 1 to 2 by being allocateda unit, from 2 to 3 by requesting aunit, and from 3 to 4 by being allocated aunit. A process can change states from 2 to 0or from 4 to 2 by releasing a unit.We represent each state of the system asSj~, where j is the state of process P1 and kis the state of process P2. For example, if thestate of P1 is 1 (P1 holds no units and hasrequested one unit) and the state of P2 is 4(P2 holds both units), then the system stateis S14. The possible changes of state in thissystem are illustrated in Figure 2.In Figure 2 the vertical edges are operationsby P1, and the horizontal edges areoperations by P2. Edges directed to theright and edges directed down represent requestsand acquisitions of units; edges directedto the left and edges directed up representreleases of units.Process P1 is blocked whenever it hasrequested a unit but no more units are available.For example, in system state S14 processP1 has requested a unit, but both unitshave been allocated to process P2. In Figure2 we can tell that P1 is blocked in S14because the node S14 has no edges labeled'T' directed away from it.Deadlock occurs in this system when oneunit of the resource has been allocated toeach process and each process requests onemore unit. This situation occurs in systemstate $33. State $33 is a total deadlock statebecause both processes are deadlocked in$33. In Figure 2 we can tell that $33 is atotal deadlock state because no edges aredirected away from node $33.Since deadlock state $33 can be reachedfrom any other state there are no securestates in the system.6. RESOURCES IN COMPUTER SYSTEMSProcesses in computer systems can interactexplicitly, for example, by exchanging mes-Computing Surveys, Vol. 4, No 3, September 1972

184 •R. C. HoltP2holdsneedsOo0P2holds O,nee,ls IP2holds 1,needs 0P2holds 1,needs IP2holds 2,needs 0PI hol,ls O,needs 02I2IP1 holds O,needs II/ T/21 1 ! 1I I I 1PI holds I,needs 0II ~ IPI hclds I ,needs I11 /1 1I2l 2Pl holds 2,needs 0FiG 2 A system with two processesand a resourceof two ~dentical umts.sages, or zmphc~tly, for example, by competingfor physical objects such as tape drives.Either type of interaction muy causeblocking of processes. We shall use the term"resource" in a special sense to mean anyobject which may cause a process to becomeblocked. "Reusable resources" will be usedto model competition for objects, and "consum~bleresources" will be used to modelexchange of signals or messages.Both types of resources consist of ~ numberof identical units which can be requestedby processes. A process requesting units isblocked until enough units are available tosatisfy its request; then the process canacquire the requested units. A process whichis not waiting for a request can release unitsof resources, thereby making more unitsavailable.Reusable resources have the followingproperties: There is a fixed total number ofunits of a reusable resource. Each unit of theresource either is available (not assigned) orhas been acquired by (assigned to) a particularprocess. A particular unit of a resourcecan be assigned to, at most, oneprocess at a time. A process can release anyunit of a resource which the process hasacquired but not yet released (assuming theprocess is not blocked waiting to acquiremore units following a request). Units cannotbe pre-empted; once a process has acquireda unit, the unit will not become availableuntil released by the process.Computing Surveys, Vol 4, No 3, September 1972

Some Deadlock Properties of Computer Systems • 185(The term "reusable resource" has beenborrowed from the term "serially reusableresource" used in IBM literature [9, 13].Murphy [20] and Russell [22] investigatereusable resources whose units can be assignedto more than one process at a time.)Some examples of reusable resources follow.EXAMPLE 1. The physical devices of thecomputer system, such as channels, core,tape drives, drums, and disks, can bereusable resources. The units of some ofthese resources will depend on the allocationstrategies of the computer system; forexample, disks may be assigned in unitsof tracks, or cylinders, or even entire disks.EXAMPLE 2. Certain information structuresshared by processes, such as records in afile and linkage pointers for buffer pools,are reusable resources. The processes mustrequest, acquire, and release access tothese information structures to guaranteethat the structures can be inspected orupdated without interference from otherprocesses. (As Dijkstra [5] puts it, at mostone process at a time should enter a "criticalsection" to inspect and update the informationstructure.)Consumable resources have the followingproperties: There is no fixed total number ofunits of the resource. Every unit of theresource is available; if a unit is acquired bya process, the unit ceases to exist. Only aprocess which is a producer of the resourcecan release units of the resource; a produceris allowed to release any number of units ofthe resource at any time (assuming the produceris not blocked waiting to acquire unitsfollowing a request). Any released unitsimmediately become available.Some examples of consumable resourcesare given below.EXAMPLE 1. The card reader produces (releases)card images that are consumed(requested and acqmred) by some process,probably the input spooling process. Thus,card images are a consumable resource.EXAMPLE 2. In many systems, externalinterrupts are received by a special interrupthandling process that interprets theinterrupt and passes a special type of messageto another process which is waitingfor that type of message. The interrupthandling process then cycles back to waitfor the next external interrupt. The interrupthandling routine consumes the externalinterrupts and produces messagesof various types. Thus, the external interruptsand the various types of messagesare consumable resources.The fundamental difference between reusableand consumable resources is that theunits of a reusable resource are never createdor destroyed, but only passed (requested andacquired) from a pool of available units to aprocess and then passed back (released) tothe pool. By contrast, units of a consumableresource are created ("produced" or released)and destroyed ("consumed" or requestedand acquired).7. SOME DEFINITIONS FROM GRAPH THEORYThe following definitions will be used in ourmodel of computer systems. A directed graphis a pair (N, E), where N is a nonempty setof nodes and E is a set of edges. Each edge inE is an ordered pair (a, b), where a and b arenodes in N. (For given nodes a and b, wewill allow E to contain more than one edgeof the form (a, b).) An edge (a, b) is said tobe directed from node a and du'ected to node b.The graph is said to be bipartite if the set ofnodes N can be partitioned into disjointsubsets l~I and RHO such that each edge hasone node in II and the other node in RHO.A sink is a node with no edges directedfrom it, and an isolated node is a node withno edges directed to or from it. If the graphcontains edge (a, b), then node a is a fatherof b and node b is a son of a. A path is asequence (a, b, c,..., r, s) containing at leasttwo nodes, where (a, b), (b, c),.-., and(r, s) are edges. A cycle is a path whose firstand last nodes are the same. (Definitionssimilar to the above are well known [2].)It follows easily from these definitionsthat in a bipartite graph having no morethan one edge directed from given node a togiven node b, there are at most 2ran edgesComputing Smveys, Vol 4, No 3, September 1972

186 • R. C. HoltFIG 3.An example of a bipartite directed graph.2) a nonempty set of resources RHO = {R1,R2,..., R,};3) a partition of RHO into two disjoint subsets,a set of reusable resources and aset of consumable resources;4) for each reusable resource Re, a strictlypositive integer te, called the to~al unitsof R~; and5) for each consumable resource Re, a nonemptysubset of the processes whichwill be called the producers of Re.The set of states Z of a general resourcesystem is the set of all general resourcegraphs for the system, which we define asfollows:in E, where m and n are the numbers ofnodes in RHO and II.The reachable set of node a is the set of allnodes b such that a path is directed from ato b. A knot is a nonempty set K of nodes suchthat the reachable set of each node in K isexactly set K. (We shall show that in certaincases, the existence of a knot in a systemstate graph is a necessary and sufficient conditionfor deadlock.) It can be shown that agraph does not contain a knot iff each nodeis a sink or has a path directed from it to asink.Figure 3 illustrates a bipartite graph withnodes {a, b, c, d} and edges t(a, b), (a, b),(a, c), (c, d), (d, c)}. In this example, node bis a sink, path (c, d, c) is a cycle, and set{c, d} is a knot.8. GENERAL RESOURCE SYSTEMSIn this section we shall define a formal modelof a system of interacting processes. Eachstate of the system will be represented by adirected graph having a node correspondingto each process and resource. Interactions inthe system will be represented by edgesdrawn from process nodes to resource nodesor vice versa. To define the system we say ageneral resource system is completely characterizedby:1) a nonempty set of processes II = [P1, P2,...,P~};A general resource graph is a bipartite directedgraph whose disjoint sets of nodes areII = {P1, P2,... ,P~} andRHO = {R1,R2, ... , Rm}, together with a nonnegativeinteger vector (rl, r2,..., rm), called theavailable umts vector. Edges directed fromprocess nodes will be called request edges,edges directed from reusable resource nodeswill be called asszgnment edges, and edgesdirected from consumable resource nodeswill be called producer edges. Each generalresource graph must have the followingproperties:1) For a given reusable resource node Re:a) the number of assignment edges directedfrom Re cannot exceed the totalmilts t3;b) r~ (the available units) is equal to thetotal units t~ minus the number ofassignment edges directed from R~;c) for a given process node P~, the numberof request edges (P~, Re) plus the numberof assignment edges (Re, P~) cannotexceed the total units te.2) For a given consumable resource node Re:a) there is a producer edge directed fromRe to process node P, iff P, is one of theproducers of Re;b) r, (the available units) is any nonnegativeinteger.Part, (lc) of this definition implies that aprocess cannot request more than the totalunits of a reusable resource. Part (2b) impliesthat a system having consumable resourcesComputing Surveys, Vol 4, No 3, September 1972

Some Deadlock Properties of Computer Systems • 187will have an (countably) infinite number ofstates.Figure 4 shows a state (a general resourcegraph) of a general resource system. In thefigure, we have illustrated the fact thatreusable resource R3 has three total units(t3 = 3) by drawing three subnodes insidethe node for R3. Thus, the available unitsr3 of R3 is the number of units which do nothave assignment edges drawn from them.We have illustrated the fact that consumableresource R2 has two available units bydrawing two subnodes inside the node forR2. The producer edge (R2, P2) indicatesthat P2 is the only process capable of releasingumts of R2. (The subnodes are notpart of the formal definitions and are drawnonly as a convenient way of representing thetotal ~nd available units.)The edges in Figure 4 can be thought ofas "waits for" relations. For example, theedges from P2 to R1 mean that process P2 iswaiting for units of resource R1. We couldhave drawn the edges in the opposite direction;in that case the edges would have represented"flow of units" relations. Forexample, edges from R1 to P2 would havemeant that units of resource R2 must flow(be assigned) to process P2.The processes in a general resource systemmap the system states into subsets of thesystem states; we will specify these mappingsby describing the operations the processescan execute. There are three types of operations:requests, acquisitions, and releases.Essentially, the general resource graph (thesystem state) xs changed: 1) by a requestoperation to have more request edges; 2) byan assignment operation to have fewer requestedges and fewer available units; and3) by a release operation to have more awilableunits. For system states S and T, wedefine these operations as follows:Requests. In state S if no request edges aredirected from node P,, thenS ~--)Twhere S and T are identical except that in Tthere are one or more request edges directedfrom node P,.Acquisitwns. In state S if there are requestConsumableResourceR2ProcessP5ProcessP2ReusableResourceR3ReusableResourceR1ProcessPlFIG 4 Example of a state in a general resourcesystem. R1 and R3 are reusable resources whosetotal umts are tl ---- 2 and t3---- 3 R2 is a consumableresource whose only producer is P2. Theavailable umts are ~1 = 1. r2 = 2, and T3 ---- 0The state is not deadlocked because it can be reducedby P1, then by P2. and then by P3edges directed from node P,, and for eachresource Re, the available units re is as largeas the number of request edges directedfrom P, to R~, thenS-L Twhere S and T are identical except that foreach request edge (P,, R~) in S: 1) r~ is decreasedby one; 2) if Rj is a reusable resource,then each request edge (P,, Re) is replacedby an assignment edge (R, P,); and 3) ifR~ is a consumable resource, then requestedge (P, Re) is deleted.Releases. In state S if no request edges aredirected from node P, and some edges (assignmentor producer edges) are directed toP, thenSA+Twhere S and T are identical except that atleast one resource R3 having one or moreedges (assignment or producer edges) directedfrom R3 to P, has its available units(re) increased; if Re is a reusable resource,then there are deleted a number of assignmentedges (R, P,) equal to the number bywhich re is increased.From the definitions of these operations,it follows that a process P~ is blocked if andonly if there is a resource node Re such thatComputing Surveys, Vol 4, No. 3, September 1972

188 • R. C. HoltS -1-> T -1-> U -1-> VPl P1 Pl PlR1 R R 2P2 P2 P2 P2:FIG 5 Examples of operations m a general resource system The system consists of consumable resourceR1 (whose only producer is process P1), reusable resource R2 (which has three total units),and processes P1 and P2 Process P1 changes the state first by requesting one umt of each resource,next by acquiring the two units, and finally by releasing three uplts of R1 plus the acquired unit ofR2 Process P2 is blocked in S because it has requested more umts than are available, but P2 is nolonger blocked in state Vthe number of request edges directed fromP, to R~ exceeds r, i.e., when P, has requestedmore units than are presently available.Figure 5 contains examples of operationsin a general resource system. When thesystem is restricted to having only reusableresources, these operations are equivalentto operations which Shoshani [24] developedpreviously and independently for a matrixbasedmodel of computer systems.9. NECESSARY AND SUFFICIENT CONDITIONSFOR DEADLOCKIn Section 4 we defined the terms "system"and "deadlock," and in Section 8 we gavean example of a system, namely, a generalresource system. In this section we will usethese definitions to develop necessary andsufficient conditions for deadlock in generalresource systems.A process is deadlocked when there is noway for the process to become not blocked.Thus, if we are able to find some sequence ofoperations which leaves a process notblocked, then we have shown that the processis not deadlocked.We shall introduce sequences of "graphreductions" as a method of testing to see ifprocesses are deadlocked. A graph reduction(by a particular process Pc) corresponds tothe best set of operations which P, canexecute to help unblock other processes; thisis eqmvalent to forcing P, to release as manyunits as possible.In order to define reductions we need aspecial symbol, OMEGA, which may bethought of as an "infinitely large" positiveinteger:OMEGA is a symbol such that forany integer ~, OMEGA ~ i andOMEGA -F ~ = OMEGA - i =OMEGA.During reductions, we will allow the availableunits re of a consumable resource toassume the value OMEGA. When a reductionassigns the value OMEGA to r~, thiscan be interpreted to mean that enoughunits of the resource could be released tosatisfy all subsequent requests. The definitionof general resource graphs required thateach consumable resource R~ have a nonemptyset of producers; however, we shalladopt the convention that if re = OMEGA,then Re may have no producers.We define reductions as follows: A generalresource graph can be reduced by any processComputing Surveys, Vol 4, No 3, September 1972

Some Deadlock Properties of Computer Systems • 189node which is not an isolated node and whichis not blocked. The reduction by P~1) for each reusable resource node Re, deletesall edges (P,, Re) and (R, P~) (foreach assignment edge (Re, P,) deleted, reis increased by one); and2) for each consumable resource node Rea) decrements re by the number of requestedges directed from P~ to Re,b) sets r~ to OMEGA if P~ is a producerof Re, andc) deletes all edges (P, Re) and (Re, P,).We say the graph is completely reducible if asequence of reductions deletes all edges inthe graph. (See Figure 6 for examples ofreductions.)Under the convention that a consumableresource Re need not have any producerswhen re = OMEGA, every reduction of ageneral resource graph leaves another generalresource graph.THEOREM 1. Process P, is not deadlocked ina general resource graph S iff a sequenceof reductions applied to S leaves a state inwhich P~ is not blocked.ARGUMENT. First assume P~ is not dead-$locked in S. Then it must be that S --~ Tsuch that P~ is not blocked in T. Let SEQbe the sequence of processes whose operationschange S to T. SEQ can be modifiedto describe a sequence of reductions whichchanges S to a state in which P~ is notblocked as follows: 1) delete each processin SEQ that has an isolated node in S; and2) delete all but the first occurrence ofeach process in SEQ. It can be shown that,from state S, any sequence of operationsby a given set of processes will result in,at most, as many available units as woulda sequence of reductions by the processesin the same set. Thus, each reduction bya process in the modified SEQ sequencewill result in at least as many availableunits as would the corresponding operationin the unmodified sequence. Thisimplies that each reduction by a processin the modified sequence will result inenough available units so that the succeedingprocess will not be blocked andcan be reduced. Hence, if P, is not dead-locked in S, then S can be reduced to astate in which P, is not blocked. Nowassume a sequence SEQ of reductionschanges S to state U in which P, is notblocked. A reduction by any process Pecan be "simulated" by an acquisition anda release (or just a release) by Pj. Thus,the sequence SEQ of reductions can be"simulated" by a sequence of operationswhich changes state S to T in which P, isnot blocked; hence, P, is not deadlockedin S.Theorem 1 means simply that if there is asequence of moves leaving P, unblocked,then such a sequence can be found usinggraph reductions. From Theorem 1, thefollowing corollary is easily proved:COROLLARY 1. If a general resource graphis completely reducible, then it is not adeadlock state.This follows from the observation that acomplete reduction deletes all edges, includingall request edges; thus, in the completelyreduced state, no process is blocked.Unfortunately, neither Theorem 1 nor itscorollary suggests a fast method of testingfor deadlock; the author knows of no betterdeadlock detection algorithm than a nearexhaustive checking of the n! different possiblereduction sequences. The reason a fastdeadlock detection algorithm has not beenfound is that reductions involving consumableresources may decrease the availableunits; consequently, the order of reductionsis important. In Sections 10 and 12 thisproblem is avoided by imposing certainrestrictions on the model, and fast detectionalgorithms are developed.Now let us define an important type ofstate for which there is a simple sufficientcondition for deadlock: An expedient state isa state in which all processes having requestsare blocked. Any state which is not expedientwill become expedient if all possible requestsare granted.Many computer systems use an "expedient"resource allocation strategy in whichall requests for available units are granted.In such a system, units are assigned onlyimmediately following requests and releases,and the system state is always expedientComputing Sulveys, Vol 4, No 3, September 1972

190 • R. C. Holt(except for the brief intervals before assignmentsare made).THEOREM 2. In a general resource graph:1) a cycle is a necessary condition fordeadlock; and2) if the graph is expedient, then a knotis a sufficient condition for deadlock.ARGUMENT. If the graph contains no cycle,then there must exist a linear ordering ofthe processes which has the followingproperty: If a path in the graph is directedto P~ from P~, then P~ appears before P~in the linear ordering.It can be shown that if processes havingisolated nodes are deleted from this ordering,then the ordering gives a sequence ofreductions that will completely reduce thegraph. Thus, if there is no cycle, then thegraph is completely reducible; hence, thegraph is not a deadlock state.If an expedient graph contains a knot,then the processes in the knot are allblocked waiting for units of resources inthe knot, and the resources in the knotcan have their available units increasedonly by (blocked) processes in the knot.Hence, all processes in the knot are deadlockedand the state is deadlocked.If all possible requests have not beengranted, i.e., if the state is not expedient, thegeneral resource graph may contain a knotand still not be a deadlock state. For example,state T in Figure 6 contains knot {P1,R2, P2, R1} and still is not a deadlock state.StateP1P2TR2State UPIP2R2State VPl[3[]P2FIG 6 Reduet,ons of a general resource graph.(State T is identical to state T m Figure 5 ) R1is a consumable resource, and R2 is a reusableresource. State T is reduced by P1 to obtain U,and U~s reduced by P2 to obtain V T is completelyreducible because the reductmns deleteall edges, therefore, T Is not a deadlock stateThe following corollary of Theorem 2 canbe proved using the graph properties ofknots.COROLLARY 2. Suppose the general resourcegraph is expedient. If P, is not a sink andno p'~th is directed from P, to a sink, thenprocess P, is deadlocked.In the next three sections we shall showthat for important special cases of generalresource systems, there are simple necessaryand sufficient conditions for deadlock, andfor security from deadlock.10. GENERAL RESOURCE SYSTEMS WITHSINGLE UNiT REQUESTSWe shall impose the following restriction onthe model.Single Umt Requests. A process may requestonly one unit at a time. In the generalresource graph this means that at most onerequest edge may be directed from anyprocess node.The restriction has the practical advantageof simplifying the algorithms used toimplement request and acquire operations.THEOREM 3. An expedient general resourcegraph with single unit requests is a deadlockstate iff it contains a knot.ARGUMENT. Since Theorem 2 states that aknot is a sufficient condition for deadlock,we have only to show that when there areonly single unit requests, a knot is a necessarycondition for deadlock. If the graphdoes not contain a knot, then from anyblocked process's node there exists a pathdirected to a sink, and such a sink isnecessarily a process node. Any suchblocked process can be shown to be notdeadlocked by showing that the graph callsuccessively be reduced by each processon the path, starting from the sink andworking backward. Hence, when there isno knot, no process is deadlocked and thestate is not deadlocked.The following results are closely related toTheorem 3. Let S be an expedient generalresource graph with single unit requests:Computing Surveys, Vol 4, No 3, September 1972

Some Deadlock Properties of Computer Systems • 1911) S is not a deadlock state iff S is completelyreducible.2) Suppose different sequences of reductionsapplied to S result in states whichcannot be reduced. Then all these resultingstates are identical.3) Process P, is not deadlocked in S iff nodeP, is a sink or has a path directed fromit to a sink.(See reference [11] for discussion and proofsof these results.)The requirement for single unit requestsin Theorem 3 is essential, as is shown by thefollowing example. Consider a system havingtwo consumable resources R1 and R2 whoseonly producers are P1 and P2, respectively.Let us suppose that no requests are pendingand no units are available. Now supposethat there is a multiple unit request byprocess P1 for one unit of R1 and one unit ofR2. As a result, P1 will be deadlocked, butthe general resource graph will not containa knot.Theorem 3 and its related results areimportant because they imply that efficientdeadlock detection algorithms are availablefor this special case of general resource systems.Algorithm 1 can be used to detect if agraph is a deadlock state by testing to see ifthe graph contains a knot. The algorithmworks by successively making all fathers ofsinks into sinks; the graph will not havecontained a knot iff all nodes become sinks.Algorithm 1 can be thought of as a simplifiedmechanism for successively reducingthe graph.ALGORITHM 1. Determination of whether adirected graph contains a knot. This canbe used to detect if an expedient generalresource graph with single unit requests isdeadlocked.1. Do for each node Q on list of sinks;2. Do for each father F of Q;3. If F is not already on list ofsinks4. Then add F to list of sinks;5. End,6. End;7. Knots = (Not all nodes are now onlist of sinks);Algorithm 2 can be used to determine if aparticular blocked process is deadlocked. Itworks by systematically tracing out allpaths leading from the process's node. Theprocess will not have been deadlocked iffsome path leads to a sink.ALGORITHM 2. Determination of whetherblocked process P is deadlocked in anexpedient general resource graph withsingle unit requests./*Switch D will tell if P isdeadlocked.*/1. Set switch D to say P is deadlocked;2. Initialize a list to contain only P;3. Do for each node Q on list while Dsays P is deadlocked;4. Do for each son S of Q;5. If S is a sink6. Then set switch D to say Pis not deadlocked;7. If S has not yet been addedto list8. Then add S to end of list;9. End;10. End;The maximum execution times of bothAlgorithms 1 and 2 are proportional to thetotal number of edges in the graph. This canbe shown by observing that the inner Dogroupof each algorithm is executed at mostonce for each edge in the graph.If more than one edge is directed from agiven node to another given node, then theseedges can be represented by a single edgetogether with an integer giving the numberof edges represented. We will say this alternaterepresentation uses weighted edges.Given that the graph uses weighted edges,then the number of edges is at most 2ran(see Section 7), and the maximum executiontimes of Algorithms 1 and 2 are proportionalto ran. (m and n are the numbers of resourcesand processes.) This fast executiontime means the algorithms can be used inpractical systems.It may be desirable in some systems totest for deadlock continually, i.e., after eachoperation which can cause a deadlock. Itcan be shown that if the system has onlysingle unit requests and if requested availableunits are immediately acquired, thenComputing Surveys, Vol. 4, No. 3, September 1972

192 • R. C.. Holtthe only operation that can cause deadlockis a request for an unavailable unit [11].Such a deadlock will necessarily involve therequesting process; hence, continual deadlockdetection can be accomplished by applyingAlgorithm 2 to any process requesting anunavailable unit. This detection method hasbeen incorporated into a simple languagewhich is being used for teaching concurrentprogramming I7].Some of the overhead required by continualdeadlock detection can be avoided bytesting for deadlock only occasionally, sayevery 20 minutes, or when some process hasbeen bloeked for a suspiciously long time.This occasional test can be accomplishedefficiently by Algorithm 1.11. CONSUMABLE RESOURCE SYSTEMSWe shall now discuss another special case ofgeneral resource systems, which we call consumableresource systems, in which there areonly consumable resources. All interactionsin such systems are explicit; we may considerthat processes can interact only byproducer-consumer relationships.We shall associate with each consumableresource R~ a set of processes, called theconsumers of Re. We will assume that everyprocess is a producer or consumer of at leastone resource. We define a claim limited consumableresource system as a consumableresource system from which has been eliminatedeach request by process P~ for resourceRe such that P~ is not one of the consumersof R e.P2R1R2FIG 7. Example of a clam1 hmlted graph for aclaim lnmted consumable resource systemP1We can now show how to characterize aclaim limited consumable resource systemby one particular graph, and how to determineif the system is secure from deadlock.For a given claim limited consumable resourcesystem, the claim limited graph is thestate of the system having: 1) zero availableunits, and 2) a request edge (P, Rj) iff P, isa consumer of R e.(Part (2a) of the definition of general resourcegraphs in Section 8 describes theproducer edges in the claim limited graph.)Figure 7 is an example of a claim limitedgraph.A claim limited graph completely characterizesa claim limited consumable resourcesystem since from it we can determine theprocesses, the resources, and the sets ofproducers and consumers. For example, theclaim limited graph in Figure 7 shows thatthe processes are/P1, P2}, the resources are/R1, R2}, the producers and consumers ofR1 are /P1, P2} and IP2}, respectively,and the producers and consumers of R2 are[P1} and tP2}, respectively.We can use the following theorem todetermine if deadlock is possible in a claimlimited consumable resource system.THEOREM 4. A claim limited consumableresource system is secure iff its claimlimited graph is completely reducible.ARGUMENT. Let the claim limited graph becalled V. First, it can be shown that anysequence of reductions of V leads to aunique graph which cannot be reduced.It can then be shown that V (now consideredto be a state in the system) is notdeadlocked iff it is completely reducible.The proof is completed as follows. It isassumed that V is not completely reducible(thus, V is a deadlock state), andit is shown that for any (supposedly)$secure state S, S ~ V. Then it is assumedthat s, sequence of reductions completelyreduces V, and it is shown that a similarsequence completely reduces any state inthe system.The claim limited graph in Figure 7 iscompletely reducible by the sequence (P1,P2). Hence, the system is secure; i.e., neitherP1 nor P2 can deadlock.Computing Surveys, Vol 4, No 3, September 1972

Some Deadlock Properties of Computer Systems • 193In theory, Theorem 4 could be used todetermine whether a simple computer systemcould deadlock. In practice, the conditionfor security (complete reducibility ofthe claim limited graph) is too strong andcould probably not be met. This means thatthe processes in a practical system can avoiddeadlock by regulating their use of resourcesaccording to some knowledge of the systemstate; however, the theory makes no assumptionsabout such "intelligent" behavior byprocesses.12. DEADLOCK DETECTION IN REUSABLERESOURCE SYSTEMSWe shall now consider the special case ofgeneral resource systems, which we callreusable resource systems, in which there areonly reusable resources.THEOREM 5. Let S be any state of a reusableresource system.1) S is not a deadlock state iff S is completelyreducible.2) Suppose different sequences of reductionsapplied to S result in stateswhich cannot be reduced. Then allthese resulting states are identical.ARGUMENT. Part (2) follows from the observations:1) that a reduction can never decreasethe available units; and 2) that areduction by given process P~ will deletethe same edges regardless of which reductionswere done previously. Since Corollary1 (see Section 9) states that completereducibihty is a sufficient condition for astate not to be deadlocked, we need onlyshow that for this case complete reducibilitybecomes a necessary condition. Therequired proof follows from the fact thatwhen the graph is not completely reducible,blocked processes which cannot bereduced are deadlocked.If each reusable resource has exactly onetotal unit, it can be shown that the conditionsof deadlock, "not complete reducibility,"and "existence of a cycle in the graph"become equivalent [11].Part (2) of Theorem 5 implies that a"reasonably fast" deadlock algorithm existsfor reusable resource systems. The algorithmsuccessively reduces the graph as long aspossible; the original graph will not havebeen deadlocked iff these reductions deleteall edges. Since every sequence of reductionswill lead to the same final graph, the algorithmwill not need to backtrack.Such an algorithm will be slowed sincefollowing each reduction a search must bemade to determine which process (if any) toreduce by next. Algorithm 3 avoids thissearching by assuming that the representationof the system state uses "wait counts"and "ordered requests" in the followingmanner: 1) for each process there is a wa~tcount which gives the number of resourceswhose available units are less than thoserequested by the process; and 2) for eachresource there is a list of processes requestingthe resource, the list being in order by thenumber of units requested.Algorithm 3 works by successively reducing(in Do-group 1) by processes which havezero wait counts and nonzero allocations.Each reduction increases the available unitsof at least one resource (in statement 3); thisin turn may result in decreasing the waitcounts (in statement 5) of other processesrequesting the resource. Notice that nosearching is required in statement 4 to locate"process Q" because "process Q" will be thenext process on the ordered list of processesrequesting resource R. Notice also that thetotal number of executions of Do-group 4 islimited by the number (m) of ordered listsof requests multiplied by the maximumnumber (n) of processes on each list. Thus,maximum execution time of Algorithm 3 isproportional to mn because Do-group 1 isexecuted at most n times (once for eachprocess), Do-group 2 is executed at mostmn times (once for each weighted assignmentedge), and Do-group 4 is executed atmost mn times (once for each weighted requestedge). (Russell [22] has concurrentlyand independently developed an equivalentalgorithm with this same maximum executiontime. Shoshani [4, 24] has developed anequivalent algorithm which does not usewait counts or ordered requests and whichrequires maximum time ran2.)ALGORITHM 3. Testing to see if a state in aComputing Surveys, Vol 4, No 3, September 1972

194 • R. C. Holtreusable resource system is completely reducible.The "list to be reduced" is initializedto contain those processes withzero wait counts and some allocations.Processes with zero wait counts and noallocations are considered already reduced.1. Do for each process node P on listto be reduced;2. Do for each resource R assignedto P;3. Increase available units ofR by units assignedto P;4. Do for each process Q whoserequest for R cannow be granted;5. Decrease wait count ofQbyl;6. If the wait count of Qis zero7. Then add Q to list tobe reduced ;.9.10.11.End-;End;End;Completely reducible = (All processnodes are now reduced);While it might appear to be costly tomaintain the wait counts and ordered listsof requests during system operation, there isa significant advantage in doing so. Theadvantage being that following a release, nosearching is necessary to find processes whichhave become able to acquire their requestedunits; these processes will be exactly theones whose wait counts become zero as aresult of the release.It can be shown that only requests forunavailable units can cause deadlock inreusable resource systems. Therefore, tomaintain continual deadlock detection, oneneed apply Algorithm 3 only when unavailableunits are requested. The request willhave caused a deadlock only if the requestingproces~ has become deadlocked; thus, Algorithm3 can be stopped (with the conclusionthat deadlock has not occurred) as soon asthe requesting process's wait count reacheszero.Processes interact only via reusable re-sources generally when the processes representnominally independent user jobs in abatch-processing system. In such a system,Algorithm 3 can be used to test for deadlock;if deadlock has occurred, it will be necessaryto terminate jobs or to pre-empt resourcesfrom jobs.13. DEADLOCK PREVENTION IN REUSABLERESOURCE SYSTEMSHabermann [8] has shown how to preventdeadlock in reusable resource systems inwhich a maximum limit (a claim) is placedon each process's need for resources. We willbriefly discuss Habermann's preventionmethod, showing how Algorithm 3 can beused to improve his original algorithm.We define a clazm matrix C as an n by mmatrix where C, gives the maximum numberof units of resource Re which will be requiredby process P, We require that 0 < C, < t~.For given process P, we require that C~j > 0for at least one resource R3 ; this means everyprocess can request at least one unit of oneresource. We define a claim limited reusableresource system as a reusable resource systemfrom which has been eliminated each requestby process P, which (for some Rj) causes thenumber of request edges (P, Re) plus thenumber of assignment edges (Rj, P~) toexceed C~j. That is, we assume processesnever request more than they claim.For a given state in a claim limited reusableresource system, the claim l~m~ted graphis constructed from the original graph (state)by adding (for all i and j) request edges(P,, Rj) until the number of request edges(P, Rj) plus the number of existing assignmentedges (Re, P~) is equal to C~.Intuitively, the claim limited graph for agiven state is formed by having all processesrequest as many units as allowed by theirclaims.To prevent deadlock, one must guaranteethat even though all processes request asmany resources as allowed by their claimsdeadlock will not occur. Thus, one mightexpect that deadlock will be prevented if thesystem is never allowed to enter a statewhose claim limited graph represents a dead-Computing Surveys, Vol 4, No 3, September 1972

Sonde Deadlock Properties of Computer Systems • 195lock state. Essentially, this is what Theorem6 states.Habermann's method employs the operatingsystem's ability to determine when togrant which requests. In terms of our formaldefinitions, this means that some of the statetransitions defined by acquire operations canbe eliminated by the operating system. Wedefine an acquisilion policy as a rule whicheliminates some of the acquisition operationsof the system, thereby creating a new systemwhich is secure. ("Secure" was defined inSection 4.) We shall say an acquisition policyis optimum if there exists no other acquisitionpolicy which ehminates fewer acquisitions.Finally, an acquisition operation is said tobe safe if it results in a state whose claimlimited graph is completely reducible.TREORE~ 6. The optimum acquisition policyfor a claim limited reusable resource systemis the one that eliminates acquisitionswhich are not safe.ARGUMENT. The theorem is proved by showing:1) that if the acquisition policy allowsan acquisition which is not safe, thennecessarily a sequence of operations existswhich leads to a deadlock; and 2) that ifonly safe acquisitions are allowed, thenany state whose claim limited graph iscompletely reducible is not a deadlockstate and can be changed only to similarstates. (The proof is discussed in detailelsewhere [8, 11].)Theorem 6 means that deadlock can beprevented (while granting as many requestsas possible) by refusing to grant requestswhen the resulting state "may lead to deadlock."We determine if a state "may lead todeadlock" by seeing if its claim limited graphis completely reducible; this can be accomplishedefficiently by Algorithm 3. Thus,Algorithm 3 is useful both for detecting andfor preventing deadlock.Habermann's algorithm to determine ifan acquisition is safe is equivalent to Algorithm3, but requires maximum executiontime proportional to mn 2 instead of mn requiredby Algorithm 3. His algorithm isused to prevent deadlock caused by competitionfor plotter and paper tape punches inthe "TRE" multiprogramming system [19].14. CONCLUSIONWe introduced reusable and consumable resourcesto model interactions among processesin computer systems. It was shownthat the technique of graph reductions canbe used 1) to determine if a state in a systemhaving reusable and consumable resources isdeadlocked; 2) to determine if a system withonly consumable resources is secure fromdeadlock; and 3) to implement deadlockprevention in a system with only reusableresources. Graph reductions are easy tounderstand, and this wide range of uses ininvestigating the deadlock problem atteststo their importance.The fast execution times of Algorithms 1,2, and 3 indicate they can be used in practicalsystems for detecting and preventing deadlock.In general, the results presented here, andthe methods used to obtain them, do notdepend greatly upon the exact definitions of"resources" and "operations." The messagepassingoperations of the SUE operatingsystem [1] (being developed at University ofToronto) have been shown to have deadlockproperties analogous to those described inthis paper [25]. Similar results can be obtainedfor systems in which interactions area result of P and V operations [6], Wake-upand Block operations [18], Wait, Post, Enq,and Deq operations [13], or Send Message,Wait Message, Send Answer, and WaitAnswer operations [3].This paper has been based on material inthe author's PhD thesis; those interested ina more leisurely and complete treatment ofthe material should refer to the thesis [11].REFERENCES1. ATWOOD, J W ; CLARK, B L ; GRusncow, MS., HOLT, R. C.; HORNIN~, J J.; SEVCIK, K. C ;AND TSICHRITZIS, D "Project SUE status report."Computer Systems Research Group,Techmcal Report CSRG-11, Umv Toronto,Toronto, Ontario, Canada, April 1972.2. BERGE, CLAUDE. The theory o/ graphs JohnWiley & Sons, New York, 1962 (originally pubhshedin French m 1958).3. I-IANSEN, PER BRINCtt "The nucleus of a multiprogrammingsystem" Comm ACM 13~ 4(April 1970), 238-241, 250.Computing Surveys, Vol. 4, No 3, September 1972

196 • R. C. Holt4. COFFMAN, E. G.; ELPHICK, M. J.; AND SHO-SHANI, A. "System deadlocks." ComputingSurveys 3~ 2 (June 1971), 67-78.5. DIJ~:STaA, E. W. "Cooperating sequential processes."Technological Univ, Emdhoven, TheNetherlands, Sept. 1965.6. DIJKSTEA, E. W "The structure of the "THE"multlprogrammmg system " Comm. ACM ll,5 (May 1968), 341-346.7. DRYER, MATTHEW. "User's manual for ToePs."Computer Systems Research Group, UmvToronto, Toronto, Ontario, Canada, 1972.8. HABERMANN, A N. "Preventmn of system deadlocks."Comm ACM 12, 7 (July 1969), 373-377, 3859 HAVENDER, J W "Avoiding deadlock in multitaskmgsystems." IBM Systems J. 7, 2 (1968),74-84l0 HOLT, A W., A~D COMMO~NER, F. "Events andconditions " Record o] the pro2ect MAC con-]ere~ce on concurrent systems and parallelcomputatwn, ACM, June 1970, 3-5211. HOLT, RICHARD C. "On deadlock in computersystems." PhD Thesis, Cornell Umv, Ithaca,N Y, Jan 1971 (Reproduced as CSRG TechnicalReport 6, Dept Computer Scmnce, Umv.Toronto, Toronto, Ontarm, Canada )12 HORNING. J J., AND RANDELL, B. "Structuringcomplex processes." Report RC2459, IBM ResearchLab.. Yorktown Heights, N.Y, May196913 IBM System/360 operating system supervisorand data management serwces IBM Form NoC28-6646-2, IBM Corp, Nov 1968.14 IBM System/360 PL/I reference manual. IBMForm No C28-8201-1, IBM Corp, March 1968.15 IBM System/360 operating system: job controllanguage IBM Form No C28-6359-8, IBMCorp, Nov. 1968.16 System/360 attached support processor system(ASP) (360S-CX-15X) version 2' system manual.IBM Form No. Y20-0305-0, IBM Corp,Dec. 1968.17 KARP. RICHARD M.; AIgD MILLER, RAYMOI'~D E."P~rallel program schemata." J Computer &System Sciences 3, 2 (May 1969), 147-195.18. LAMPSON, S. W. "A scheduling philosophy formultlprocesslng systems " Comm. ACM 11, 5(May 1968), 347-360.19 MCKEAG, R M "The multlprogrammmg system."Queen's Umv. Belfast, Dept. ComputerScience, Belfast, N. Ireland, 197220 MURFHY, J E. "Resource allocation with Interlockdetection in a multltask system" InProc. AFIPS 1968 Fall Joml Computer Con].,Vol. 33. Pt 2, AFIPS Press, Montvale, N J.,1169-1176.21 RAPPAPORT, ROBERT L "Implementing multiprocessprimitives in a multtplexed computersystem" Masters Thesis. Dept Eleemcal Engmeermg(Project MAC), Massachusetts InstituteTechnology, Cambmdge, Mass, Nov.196822. RUSSELL, R D "A model of deadlock-free resourceallocation." PhD Thesis, Dept. ComputerScience, Stanford Umv, Stanford, Cahf,July 197123 SALTZER, JEROME HOWARD "Traffic control in amultiplexed computer system" PhD Thesis,Project MAC, Massachusetts Institute Technology,Cambridge, Mass, July 196624 SHOSHANI, A ; A~D COF~MAN, E G, JR "Detectmn,prevention, and recovery from deadlockm multiprocess, multiple resource systems."Techmcal Report 80, Computer Sciences Lab,Dept Electrical Engineering, Princeton Univ,Princeton, N J., Oct 1969.25. VERNER, YvEs "On process commumcatmn andprocess synchronizatmn " Masters Thesis. DeptComputer Science. Umv Toronto. Toronto,Ontarm, Canada, Oct 1971Computing Surxeys, Vol 4, No 3, September 1972