Deadlock prevention in concurrent real-time systems

Real-Time Systems, 5, 305-318 (1993) © 1993 Kluwer Academic Publishers. Manufactured in The Netherlands.

Deadlock Prevention in Concurrent Real-Time Systems*

SUSAN DAVIDSON AND INSUP LEE Computer and Information Science, University of Pennsylvania, Philadelphia, PA 19104

VICTOR FAY WOLFE Computer Science and Statistics, University of Rhode lsla,~, Kingston, RI 02881

Abstract . To meet consistency requirements found in concurrent applications, a process must be guara~ateed that it will be able to use all resources in a set of passive resources (such as shared data structures). To provide predictable execution time required in real-time systems, a process also needs guaranteed access to at least one of a set of active resources (such as processors) associated with each passive resource. As such, a concurrent real- time-process has AND-OR resource requirements. If locking is used to provide exclusive access to resources, deadlock is possible since processes can request additional resources while holding other resources. Deadlock detection and recovery techniques and deadlock avoidance techniques typically involve preempting resources or terminating processes, and are therefore inappropriate for real-time systems that require the execution time of processes to be predictable. This paper describes a general resource request condition that we prove prevents deadlock in AND-OR systems. It also describes how we use this AND-OR deadlock prevention technique in a concurrent real-time system.

1. Introduction

In concurrent real-time applications, there are consistency constraints on the use of shared resources and timing constraints on execution that must be met for performance to be correct (Stankovic 1988), (Wolfe, Davidson and Lee 1990). To meet consistency constraints, a process must be guaranteed that it will be able to use all resources in a set of passive

resources (such as shared data structures). Each passive resource has actions which can be executed on any one of a set of associated active resources (e.g., processors), each of which may additionally be associated with other passive resources. To guarantee that the actions can be predictably executed by the process, the run-time support system must also provide the process with exclusive access to at least one of the associated set of active resources for each passive resource. As such, concurrent real-time processes have AND- OR resource requirements (Shih and Stankovic 1990). For example, the resource request of a process that requires passive resources { prt . . . . . p r , }, where p r i has the set of associated active resources {aria , . . . , ari,mi}, can be expressed by the run-time support system as:

(pr 1 A ( a r l , l V . . . V arl,m,)) A . . . (pr n A (am, 1 V . . . v arn,mn ) (1)

To provide exclusive use of passive and active resources, we are interested in tocking techniques. A drawback of this approach is that deadlock may occur because processes can hold locks on resources while waiting for other locks to be granted.

*This work is supported in part by the following grants: ONR N000014-89-J-1131 and ARO DAAG-29-84-k-0061.

306 S. DAVIDSON, I. LEE AND V.E WOLFE

EXAMPLE 1. Suppose that the resources in the system are:

• passive resource pr l , with associated active resources ar 1 and ar3;

• passive resource pr2, with associated active resources ar 1 and ar2;

• passive resource pr3, with associated active resource ar 3.

Suppose that process ql requires passive resources pr l and pr2, which is expressed by the ran-time support system as the resource request

p r I A (ar I V ar3) A p r 2 A (ar 1 V ar2).

Process q2 requires passive resources p r 2 and p r 3, which is expressed by the run-time support system as the resource request

pr2 A (ar 1 V ar2) A p r 3 A ar 3.

The concurrent execution of these resource requests proceeds as follows:

process ql

get pr l

get ar3

waits for p r 2

process q2

get p r 2

get arl

get p r 3

wait for ar 3

Deadlock has occurred: process ql waits for resourcepr2 that is held by process qz, while process q2 waits for resource ar3 that is held by process ql.

In general, deadlock can be treated in one of three ways: detection and recovery, avoidance, or prevention. Both deadlock detection and recovery techniques and deadlock avoidance techniques (Knapp 1987), (Elmagarmid 1986), (Shaw 1974), (Rozenkrantz, Steam and Lewis 1978) involve preempting resources or terminating processes, and are therefore inappropriate for real-time systems in which the elapsed execution time of processes must be predictable. We therefore look to prevention for handling deadlock. 1

For the single-resource request system model, in which each process requests resources one at a time, it is well known that a cycle of processes waiting for each other is a necessary and sufficient condition for deadlock. Deadlock prevention techniques for the single resource request model typically constrain processes to make requests in a fixed order (Shaw 1974), (Havender 1968), (Coffman, Elphick and Shoshani 1971). The AND-OR request model (Chandy, Mosra and Haas 1983), (Knapp 1987) generalizes the single request model by allowing the request to be any formula built up from atoms representing resources that are combined with AND and OR operators; the formula in (1) is an example of such a request. In this model, a cycle is still a necessary condition for deadlock but not sufficient due to possible multiple opportunities for satisfying an OR request (Knapp 1987), (Holt 1972). The single-resource model deadlock prevention techniques of fixed order resource requests also do not apply straightforwardly to an AND-OR model of a concurrent real- time system. One problem is that it is not sufficient to merely include passive resources

DEADLOCK PREVENTION IN CONCURRENT REAL-TIME SYSTEMS 307

in the ordering; active resources must be considered. In Example 1, both processes could request passive resources according to the ordering pr 1 < pr z < pr 3, yet deadlock could still occur due to the requests for active resources generated by the run-time system. The run-time system would generate the following sequence of requests: for qi it would be (1) pr 1 A (ar 1 V ar3), (2) pr 2 A (ar 1 V ar2); while for q2 it would be (1) pr2 A (at 1 V ar2), (2) pr 3 A ar 3. The concurrent execution of these sequences of requests could be the same as that in Example 1, which results in deadlock. Another problem is that once resources are ordered, it is not clear what conditions should be placed on the form of requests to guarantee that deadlock does not occur.

Our goal is to develop a general resource request condition that can be proven to prevent deadlock in AND-OR systems, and apply it to our model of a concurrent real-time system. In Section 2, we start by providing a general characterization of deadlock in AND-OR systems and developing a general request condition which probabiy prevents deadlock. In Section 3, we define our model of concurrent real-time systems as instances of AND-OR systems, discuss the effects of various orderings of resources, and show how the general deadlock prevention technique can be applied. Section 4 discusses related work concerning general deadlock treatment and deadlock treatment in real-time systems. Section 5 summar- izes, briefly describes the implementation of our results, and discusses future work.

2. Deadlock Prevention In AND-OR Systems

The system is composed of a set of processes, Q and a set of resources R. At each step of its execution, a process q ~ Q either requests resources, releases resources, or is blocked. We say that a process holds a resource at a particular step in its execution if the resource has been granted to the process but not yet released by the process, and denote the set of resources held by q as holdq. Furthermore, we denote the set of resources that are held by no process as free. A resource request for a process q, denoted reqq, is expressed as an AND-OR formula built up from atoms which are resources using logical connectives "and" (A) and "or" (V). Equation (1) from Section 1 is an example of a resource request. When a process receives a resource, the atom in the request formula becomes true; until then the atom is false. A process's resource request is said to be satisfied when q holds resources such that the resource request formula evaluates to true. Until its request is satisfied, the process is blocked and cannot execute. A resource release is a simple conjunction of resources that are held by the process; that is, process q can release a single resource or a set of resources simultaneously.

We describe blocked processes and the problem of deadlock in the system using a wait- for graph.

DEFINITION 1. A wait-for graph (WFG) is a labeled directed graph where:

• There is a node for each process q E Q. • Each edge p r q denotes that process p is waiting for resource r held by process q.

When process p makes a resource request, reqp, each resource requested that is in rfree is granted to p, i.e, is added to holdp. I f the resource is not in free, then the edge p ~ q

308 s. DAVIDSON, I. LEE AND V.F. WOLFE

is added to the WFG for each resource r ~ reqp Cl holdq. When process p's request is satisfied, every such outgoing edge from node p is removed. When p releases a resource r, the resource r is removed from holdp. Furthermore, if there is some process p ' waiting for resource r, then an edge p' _5, p is chosen to be removed, and r is added to holdp,, indicating thatp ' has been granted r. Since there could be other processes also waiting for r, indicated by other incoming edges to p labeled with r, each such edge must be redirected to point to node p', i.e., each edge q & p is replaced by the edge q & p'.

We now define deadlock in our system and then use the WFG to develop a necessary condition for its occurrence.

DEFINITION 2. A process is deadlocked iff it is a member of a set of blocked processes, each of whose resource request can only be satisfied by a resource held by some other member of the set.

If all resource requests are simple conjunctions, then a necessary and sufficient condition for deadlock is well-known to be a cycle in the WFG (Holt 1972). A cycle is also a necessary condition for deadlock with AND-OR requests. Note however that a cycle is not a sufficient condition as shown in the following example:

• process ql holds rl and r2, and requests r3; • process q2 holds r3 and requests r 4 V 1"2; * process q3 holds r4.

The WFG for this scenario contains the cycle ql r q2 "~ ql. However, there is no deadlock since process q3 is not blocked but merely executing; process q2's OR request can be satisfied when q3 releases r4. Unfortunately, a necessary and sufficient condition for deadlock in general AND-OR systems is not known (Knapp 1987).

In systems where resource requests are simple conjunctions, a well known technique for deadlock prevention is to give a total order of resources "I , and require that the maximum resource held by each process p, max(holdp), be "smaller than" the resource being requested by p, reqp. Restated, the AND request condition for deadlock prevention in AND resource request systems is:

max(holdp) .~ reqp

(Note that reqp is a single resource, but that in general AND-OR systems it will be a set of resources). It is easy to show that if each process follows this resource request condition, then cycles cannot occur in the WFG and deadlock is prevented.

We now extend this technique to derive a resource request condition for deadlock prevention in general AND-OR systems. Let max(reqp) to be the maximum resource in process p's current request. The request condition then becomes:

AND-OR Request Condition A process's request reqp can be satisfied by the single resource max(reqp), and max(holdp) .~ max(reqp).


To prove that the AND-OR request condition prevents deadlock, we first observe that if each process's request can be satisfied by granting the maximum resource appearing in the request, then a necessary condition for deadlock is a cycle in the edges representing the maximum resource requests. More precisely:

DEFINITION 3. A max-request edge in the WFG for a node p is the outgoing edge from p labeled with the maximum resource (according to the resource ordering ~ ).

LEMMA 1. If every process meets the AND-OR Request Condition and deadlock occurs, then there must be a cycle in the max-request edges of the WFG.

Proof Consider the subgraph G induced by the max-request edges in the WFG. Each node in G has at most one outgoing edge, since the edges are max-request edges and -~ is total. Each node representing a deadlocked process p must have exactly one outgoing edge, other- wisep would not be blocked and could not be deadlocked. Furthermore, the process holding the resource labeling the max-request edge o fp must be deadlocked, otherwise it would eventually release the resource to p, satisfying p's request and unblocking p. The claim is that if there is a deadlock, then there must be a cycle in G. To see this, pick a node representing a deadlocked process and perform a depth-first search. Since the graph is finite, there are a finite number of nodes representing deadlocked processes and a back- edge must eventually occur, indicating a cycle of max-request edges. []

Note that the AND-OR Request condition implies the AND Request condition: If processes have AND resource requirements, then only single, ordered resource requests are allowed. Furthermore, all the edges in the WFG are max-request edges, so a cycle of max- request edges is the same as a cycle in the WFG.

THEOREM 1. If each process meets the AND-OR Request Condition, then deadlock cannot occur .

Proof Assume the contrary, that all processes meet the AND-OR Request Condition and deadlock occurs. By Lemma 1, there must be a cycle C of max-request edges in the WFG. Let p be the node with the outgoing edge p r q, where r is the maximum resource labeling a max-request edge in C. Resource r must be in hold(q) and, since q follows the AND-OR request condition, r < max(reqq). However, this is a contradiction of the definition of r being the maximum resource requested in C. []

Hence, requiring each process to meet the AND-OR Request Condition is a correct deadlock prevention scheme for AND-OR systems in which no assumptions are made about the way in which resource requests are processed.

The immediate question which arises is whether this technique can be used for arbitrary AND-OR requests rather than the extremely restricted form required by the AND-OR Re- quest Condition. It turns out that the answer is "yes," that is, we can always convert an arbitrary AND-OR request into a sequence of requests that meet the AND-OR Request Condition. The reason for this is as follows: any AND-OR request can be converted to

310 s. DAVIDSON, I. LEE AND V.F. WOLFE

conjunctive normal form (CNF), fl Af2 A . . . Af t , where eachj~ is a disjunction of single resource requests. Furthermore, since A is commutative, the f s can be ordered so that the maximum resource appearing in3~ is less than or equal to the maximum resource appearing infi+l for i = 1 . . . n - 1. Using associativity, the disjuncts can be grouped into maximal conjunctions of disjuncts gj = j~ A Jk+l A . . . A 3~, where the maximum resource appearing in each of thef /s are the same. The process must then request each gi in order, waiting for the request to be satisfied before requesting gi+l. Note that the AND-OR request condition is met since each gi can be satisfied by a single resource, which is the maximum resource appearing in each 3~ in gi.

In general, deadlock prevention using this technique may not be viable since the conver- sion of the AND-OR request to CNF can involve an exponential blow-up in terms. However, in our real-time system model the requests are already in CNF and the result is quite useful as will be seen in the next section.

3. Deadlock Prevention in Concurrent Real-Time Systems

We now consider which resource ordering -~ to adopt, since it has tremendous impact on the sequence of resource requests that can be generated using the AND-OR Request condition. Due to our system model, this is influenced by the association of active to passive resources.

Our concurrent real-time system model consists of a set of resources and a set of processes. The resources R are used exclusively mad are partitioned into a set of passive resources, PR, and set of active resources, AR, where PR tq AR = 0 and P R O AR = R. Each passive resource pr has an associated set of active resources, assoc(pr), which are the only active resources that can execute actions onpr. Each process needs exclusive use of a set of passive resources; to obtain these resources, it makes a sequence of valid single passive resource requests. That is, given an ordering of the passive resources, the process ensures that its requests meet the AND-OR Request Condition. To use the passive resource, the process must also exclusively hold at least one of the passive resource's associated active resources; we assume that the run-time support system generates valid AND-OR active resource requests for the passive resources acquired by the process.

We expect the system to behave as follows: processes are allowed to use passive resources as soon as possible after they have been granted. Furthermore, since active resources can be shared by many passive resources, active resources should be held for as short a t ime as possible to increase their utilization; that is, the run-time support system should not acquire them earlier than necessary.

To see the effect that these conditions have on acceptable resource orderings, consider the following two orderings:

1. Create a total of all resources which orders all passive resources before active resources; 2. Create a total of all resources which orders all active resources before passive resources.

The first ordering suffers from the fact that processes cannot use passive resources as soon as they are granted because the active resource requests are generated after all passive

DEADLOCK PREVENTION IN CONCURRENT REAL-TIME SYSTEMS 31 1

requests have been made. The second ordering suffers from the fact that the utilization of active resources is poor because all active resources must be obtained before the passive resources are requested. Furthermore, since the process may not know what passive resources it will need in the future, it must obtain and hold enough active resources to cover any possible passive resource request.

Another possibility is to arbitrarily order the resources, both active and passive. This technique may also resttlt in a violation of the desired system behavior, as seen in the following example.

EXAMPLE 2. Suppose that

" assoc(prl) = {ar 1, ar2}; • assoc(pr2) = {ar3} ; • pr l -~ arl "~ pr2 ~ ar2-~ ar3; • process p wishes to use both prl and p r 2.

Given this ordering, the only valid request sequence is: (1) prl; (2) pr2; (3) ar 1 v ar2;

(4) ar 3. A problem with this ordering is that p cannot use p r 1 until pr2 is granted. A better ordering of resources would be:

prl ~ arl -~ ar2 ~ pr2 ~ ar3

This would allow the following valid request sequence, in which the active resources are obtained as soon as the passive resource has been granted: (1) prl; (2) arl V ar2; (3) pr2; (4) ar3. Now p can use pr~ before requesting p r 2.

Clearly, we must place restrictions on how passive and active resources are interleaved in the resource ordering. Furthermore, these restrictions depend on the association between active and passive resources.

3.1. The Resource Ordering

To improve utilization of active resources, the system should request the associated active resources after the passive resource has been requested. This requirement implies that we should order each passive resource before at least one of its associated active resources. To allow a passive resource to be used as soon as possible, the system should request the associated active resources before the next passive resource is requested. This requirement implies that for every pair of passive resources pri, prj such that pri ~ prj, process p~) must be ordered after all of the active resources associated with pri.

EXAMPLE 3. Suppose that

* a process wishes to use passive resources prl , pr2 and pr3;

, p r 1 .~ pr2 ~ pr3; * assoc(prl ) = {ar 1, ar2}, assoc(pr2) = {ar2, ars}, and assoc(pr3) = {ar4}.


To be able to use each passive resource as soon as it is obtained, ordering -~ must obey the constraints:

• pr I ~ arl or prl ~ are; e pr 2.{ are orprz ~ ar3; s p r 3 .~ ar4; • ar 1 ~ pr 2 and are .~ pr2; o a r z .~ pr 3 and ar3 ~ pr3.

One total ordering -~ which satisfies these constraints is:

prl -~ arl -~ ar2-~ prz-~ ar3-~ pr3 ~ ar4. (2)

Thus, the process issues the following valid sequence of resource requests:

(1) prl; (2) arl V are; (3) prz; (4) ar 2 V ar3; (5) pr3; (6) ar 4.

Unfortunately, a total ordering of resources that obeys the above constraints may not always exist since active resources can be shared between passive resources. If we modify Exam- ple 3 so that assoc(pr3) = {ar3}, we get a contradiction: ar 3 ~ pr 3 -~ ar 3. The best we can do in this situation is to divide passive resources into equivalence classes, where pr i and prj are in the same equivalence class if and only if they have the same maximum associated active resource. We then allow the system to wait to acquire the associated active resources until all passive resources in the equivalence class have been obtained. Continuing with the problematic modification of Example 3, pre and pr3 would be placed into an equivalence class and both ordered before ar3. One possible ordering to meet the modified constraints is therefore:

arl ~ pra -~ are-~ pr2 ~ pr3 ~ ar3. (3)

Using this ordering, the sequence of valid resource requests generated by the process would be: (1) prl; (2) art v ar2; (3) pr2; (4) pr3; (5) (ar 2 V ar3) A (ar3).

To formally describe the resource ordering constraints discussed above, let max active(pr) be the maximum active resource in ordering -~ associated with passive resource pr. The constraints on the resource ordering then become:

C1 Ypr(pr ~ max__active(pr))

C2 YpriYprj(pr i -~ prj ~ max_active(pri) -~ prj) A (max_active(pri) = max_active(prj))

To mechanize the derviation of an -~ ordering that meets constraints C1 and C2, we use the following method. We restrict our attention to only active resources which will actually be used, i.e. those that are associated with at least one passive resource.


Resource Ordering Method

1. Initially, set -~ to include an arbitrary total order of the active resources. This ordering is used to define the function max ac t ive .

2. For each passive resource, pr , add p r -~ m a x a c t i v e ( p r ) .

3. For every active resource a r and every passive resource p r such that a r m a x a c t i v e ( p r ) , add a r -~ pr .

4. Passive resources with the same maximum associated active resource are then arbitrarily ordered and added to -~ to create the final (total) ordering of all resources. That is, if p r l , pr2 . . . . . p r n ~ P R with m a x a c t i v e ( p r l ) = m a x ac t i v e (p r2 ) = . . . = m a x a c t i v e ( p r n ) , then arbitrarily create a total ordering o f p r l , pr2 . . . . . prn , p r 1 -~

p r 2 -~ . . . -~ prn. 5. Let -~ be the smallest transitively-closed order that is compatible with Steps (1)-(4).

For instance, using the Resource Ordering Method on the problematic modification of Ex- ample 3 produces:

ar l -~ p r t -~ ar2-~ pr2 -~ pr3 -~ ar3

(with the arbitrary ordering in Step 4 being pr2 -~ pr3), which is identical to the ordering (3) that we proposed earlier.

THEOREM 2. The order ing ~ genera ted by the R e s o u r c e Order ing M e t h o d is total a n d m e e t s cons t ra in t s C1 a n d C2.

The ordering -~ orders each pair of resources r i and rj. Assume the contrary, that resources ri and rj are not ordered. Since Step 1 orders all active resources, at least one of r i and rj must be a passive resource.

case 1: r / a n d 1) are bo th p a s s i v e resources .

Since Step 4 arbitrarily orders all passive resources with the same maximum associated active resource, ri and ~ must have different maximum associated active resources. Without loss of generality, let max ac t i ve ( r i ) -~ m a x ac t i v e ( r j ) . By Step 2, ri

m a x a c t i v e ( r i ) ; by Step 3, m a x ac t i v e ( r i ) .~ rj. By transitivity of -~ , we conclude that ri -~ rj.

case 2: r i is a p a s s i v e re source a n d rj is an ac t i ve resource .

Since rj and m a x ac t i ve ( r i ) are both active resources, they must either be the same resource or be ordered in Step 1. I f they are the same resource, then r i -~ I) by Step 2. I f r j -~ max__ac t i ve ( r i ) , then rj -~ r iby Step 3. Lastly, if max ac t i ve ( r i ) .~ rj, then r i -~ rj holds transitively since Step 2 orders r/ -~ max ac t i ve ( r i ) .

Thus, in both cases resources r i and rj are ordered.

The ordering -~ is well-defined, i.e., if r i .~ t ) holds then i) -~ r i does not hold. To simplify the proof, we observe that the -~ relation developed in Steps 1-3 of the Resource Ordering Method can be modeled as a directed graph ~ in which the nodes are resources

314 s. DAVIDSON, I. LEE AND V.E WOLFE

and there is an edge r i -~ rj iff rl -~ rj. Since -~ is well-defined iff the corresponding graph is acyclic, it is enough to show that ff~ is acyclic. Since the transitive closure of an acyclic graph remains acyclic, we are assured that the graph remains acyclic after Step 4 and hence that the ordering ~ is well-defined.

In what follows, we use variables ar to denote active resources, and pr to denote passive resources.

Suppose ff~ contains a cycle. For each passive resource node pr i in the cycle, we note that its outgoing edge must be of formpri ~ max_active(pri) since the only edges from passive to active resources are added in Step 2. The incoming edge must be of form arj

pri added in Step 3, since neither Steps 1 or 2 add any incoming edges to passive resources. But in this case arj -~ max active(pri) (by definition of Step 3), and ar] max active(pri) was already added in Step 1. Hence we can replace the path arj ~ pr/ max active(pri) by an edge added in Step 1, arj ~ max_active(pri). Using this technique, we can eliminate all passive resources along the path, and show that the path must have existed in Step 1, a contradiction of the fact that the ordering on active resources is total.

The ordering ~ meets constraints C1 and C2. Step 2 ensures that -~ meets constraint C1. For all passive resource pairs that have the same maximum associated active resource, the ordering -~ trivially meets constraint C2. Let pr i and prj be any passive resource pair that do not have the same maximum associated active resource and assume that pr i .~ prj. By Step 2, prj .~ max_active(prj). By transitivity, pr i -~ max active(prj). By Step 3, since pri ~ max__active(prj), then max_active(prfl ~¢ max_active(Pri). Since the ordering priand prj do not have the same maximum associated active resource and -~ is total, then it must be that max__active(pri) -~ max_active(prj). By Step 3, this yields max active(pri) ~ prj. Thus, when pri -~ prj, then max active(pri) ,~ p~, which meets constraint C2. D

Note that there may be other resource orderings that meet conditions C1 and C2 which would not be produced by the Resource Ordering Method. In particular, using the method on Example 2 with the same initial ordering of active resources would produce:

art -~ prl ~ ar2-~ pr2-~ ar3,

which is different from the ordering shown in the example. It is an interesting open question to quantify when one ordering is "better" than another, and to ask whether a clever way of initially ordering the active resources (Step 1 of the method) would produce a better ordering.

3.2. Examples of Deadlock Prevention

We now show how using the Resource Ordering Method and having processes follow the AND-OR Request Condition can result in a system where processes must only be aware of the ordering of passive resources, processes may use the passive resources as soon as they are obtained, and deadlock is prevented.


Recall that in Example 1:

• PR = {pr 1, pr2, pr3}; • AR = {arl, ar2, ar3} ; • assoc(prl , ) = {arl, ar3}; assoc(pr2) = {arl, ar2}; assoc(pr3) = {at3}.

Using the Resource Ordering Method with an active resource ordering of ar 1 ~ ar 2 .~ ar 3, and an ordering of passive resources in the same equivalence class o fpr l -~ pr3, we would get the total ordering:

arl ~ pr2-~ ar2-~ prl -~ pr3 ~ ar3.

The run-time support system would make available to process designers the passive resource ordering pr2 -~ prl -~ pr3, and the equivalence class partition {pr2} and {prl, pr3}.

A process designer would then design each process to make ordered requests for all resources that it needs and would include all resources from an equivalence class in the same request. For instance, a process that needs to use passive resources prl , pr2 and pr 3 in Example 1 would execute as indicated in the left column:

Process Request

request (pr2)

can use pr 2 request (prb pr3)

can use pr 1 and pr 3 release (pr b pr2, pr3)

Run-Time System Generates

request(pr2) request(ar 1 v ar2)

request(prl) request(pr3) request((arl V ar3) A ar3)

The run-time support system would generate the process's requests as shown in the right column above. As we can see, the process only requests passive resources and can use the passive resources as soon as its request (in the left column above) is granted. Further- more, the actual resource requests in the right column above meet the AND-OR Request Condition so that deadlock is prevented.

Applying this technique to the processes of Example 1, in which process ql has resource requirement {pr~, pr2}, and process q2 has resource requirement {pr2, pr3} results in the following requests:

process ql

request (pr2)

request (prl)

system for ql process q2

request(pr2) request (pr2) request (arl V ar2) request (prl) request (pr3) request (ar 1 V ar3)

system for q2

request (pr2) request (ar 1 V ar2) request (pr3) request (ar3)

316 S. DAVIDSON, I. LEE AND V,E WOLFE

It is easy to see that the deadlock which occurred in the execution described in Section 1 cannot occur with this request sequence because whichever process receives prz will execute to completion and then will release pr 2 to the other (waiting) process--thus preventing deadlock.

4. Related Work

Most previous work concerning deadlock has been in the area of deadlock detection (see (Knapp 1987) for a survey and more recently (Choudhary, Kohler, Stankovic and Towsley 1989), (Belik 1990)), which, as we have stated, is inappropriate for many real-time systems because associated deadlock recovery techniques can cause unpredictable execution time for processes. To our knowledge, deadlock prevention in AND-OR systems has not been addressed in other work.

Shih and Stankovic (Shih and Stankovic 1990) present an AND-OR model of concurrent real-time Ada systems along with distributed deadlock detection and resolution techniques. Since Ada systems do not have flexibility in determining the request order for resources (rendezvous requests), the AND-OR Request Condition cannot be enforced. In this case, deadlock detection and resolution techniques, such as (Shih and Stankovic 1990), are required. For AND model single-processor real-time systems, Rajkrumar, Sha et al. have developed the priority ceiling protocol that prevents deadlock. Their protocol has the additional property of limiting priority inversion among processes with static priorities and therefore improves the predictability of the execution time of processes (Sha, R, ajkumar and Lehoczky 1987), (Rajkumer 1989), (Rajkumer, Son and Chang 1991). However, the priority ceiling protocol requires that each resource know the maximum priority of a process that could lock it; this requirement can limit the protocol's usefulness in general systems where locking patterns are not known at system design time. Also, the priority ceiling protocol is restricted to static priorities; since our deadlock prevention technique does not depend on priorities, it can support deadlock prevention in a system with dynamic priorities.

5. Conclusion

We have shown that requiring processes to meet the AND-OR Request Condition wiU prevent deadlock in systems where processes can make AND-OR requests. Since the AND- OR model is a generalization of the AND, OR, and single-request models, requiring processes to meet this request condition will also prevent deadlock in these simpler models. In fact, for single-request models, the AND-OR Request Condition becomes exactly the traditional ordered request technique that has been widely used to prevent deadlock.

We used this general result to show how deadlock can be prevented in concurrent real- time systems where:

• resources are partitioned into passive and active resource sets; • each passive resource has an associated set of active resources; • processes require guaranteed exclusive use of a set of passive resources to maintain con-

sistency constraints;


• for each passive resource that a process requires, it also requires guaranteed access to an associated active resource so that it can predictably meet timing constraints;

" processes are only aware of passive resources, the system requests active resources; • processes are allowed to use passive resources as soon as possible after they have been

granted; • active resources are held for as short a time as possible.

To meet these additional requirements, we imposed constraints on the total ordering of resources and presented an algorithm, the Resource Ordering Method, which generates a total order of the resources that meets those constraints. Thus, by using the Resource Ordering Method to order resources and by requiring processes to request passive resources in equivalence classes based on the ordering, we showed that the resource requests generated by the run-time system satisfy the AND-OR Request Condition and therefore prevent deadlock.

Several interesting extensions to our technique arise by dropping the restriction that processes only make single passive resource requests. Note that currently only the system may generate general AND-OR resource requests, and that these only involve active resources. It should be possible to relax this restriction, and have the system ensure that all possible future active requests will be valid. For example, suppose assoc(pr l ) = {arl} , assoc(prz)

= {ar2}, assoc(pr3) = {ar3}. The ordering produced by the Resource Ordering Method would be

prl ~ arl -~ pr2 ~ ar2 ~ pr3 ~ ar3

Now suppose a process wishes to acquire pr2, and then p r 1 V pr3. Based on the ordering -~ , the initial sequence of requests generated by the system would be (1)pr2, (2) ar 2, (3)

p r 1 V pr3. At this point, the active request generated by the system depends on whether p r 1 or pr3 was acquired. I fp r l was acquired, the system cannot generate the associated active resource request for prl without violating the AND-OR Request Condition. However, i f p r 3 was acquired, the system can generate a valid request for ar 3. Since the system should not request a passive resource unless it can guarantee that it can generate a valid active resource request, the sequence of requests generated by the system should be (1 )p r 2, (2) ar2, (3 )pr 3, (4) ar 3.

Another interesting solution results from dropping the conditions on the resource ordering. In this case, the following method of ordering resources will guarantee that for any valid AND-OR passive resource request, the corresponding active resource request will always be valid, but delayed until all passive resources have been obtained.

1. Create an arbitrary ordering of all active resources. 2. Place the passive resources into ordered equivalence classes based on their maximum

associated active resource. 3. Add an arbitrary ordering of passive resources within the same equivalence class. 4. Order all passive resources before all active resources.

Our interest in developing deadlock prevention techniques for AND-OR systems arises from the implementation of a programming system for concurrent real-time applications (Wolfe, Davidson and Lee 1991), (Wolfe 1991). Our system has language constructs to


express timing and consistency constraints in programs, and a distributed run-time support system that enforces constraints through a special form of locking. The run-time system allows processes to acquire locks so that use of resources is guaranteed and timing constraints can be met, and so that shared resource consistency constraints are maintained. We use the Resource Ordering Method to order resources in our current implementation of this system, and have designed the preprocessor for C so that lock requests for processes meet the AND-OR Request Condition thus preventing deadlock. As future work, we intend to examine how to improve the performance of our current implementation, possibly by allowing passive resource managers to communicate with each other to optimize their requests for active resources, and by determining how to create "better" initial resource orderings.

Note

1. For a classification of request models and deadlock see (Knapp 1987).

References

Belik, F. 1990. An efficient deadlock avoidance technique. IEEE Transaction on Computers. 39: 882-888. Chandy, K.M., Misra, J., and Haas, L. 1983. Distributed deadlock detection. ACM Transactions on Computer

Systems. 1: 144-1566. Choudhary, A., Kohler, W.H., Stankovic, J.A., and Towsley, D. 1989. Modified priority based probe for distributed

deadlock detection and resolution. 1EEE Transactions on Software Engineering. 15: 10-17. Coffman, E., Elphick, M., and Shoshani, A. 1971. System deadlocks. ACM Computing Surveys, 3: 67-78. Elmagarmid, A. 1986. A survey of distributed deadlock detection algorithms. SIGMOD Record. 15: 37-45. Havender, J.W. 1968. Avoiding deadlock in multitasking systems. IBM Systems Journal. 2: 74-84. Holt, R. 1972. Some deadlock properties of computer systems. ACM Computing Surveys. 4: 179-196. Knapp, E. 1987. Deadlock detection in distributed databases. ACM Computing Surveys. 19: 304-328. Misra, L and Chandy, K.M. 1982. A distributed graph algorithm: knot det~tion. ACM Transactions on Pro-

gramming Languages and Systems. 4: 679-686. Rajkumar, R. 1989. Task S)~achronization in Real-Time Systems. Ph.D. thesis, Carnegie Mellon University. Rosenkrantz, D.J., Stearn, R., and Lewis, P. 1978. System level concurrency control for distributed database

systems. ACM Transactions on Database Systems. 3: 178-198. Sha, L., Rajkumar, R., and Lehoczky, J.P. 1987. Priority inheritance protocols: an approach to real-time synchro-

nization. Tech. Rep. CMU-CX-87-181, Carnegie Mellon University. Sha, L., Rajkumar, R., Son, S., and Chang, C. 1991. A real-time locking protocol. IEEE Transactions on Com-

puters. 40: 793-800. Shaw, A. 1974. The Logical Design of Operating Systems. Englewood Cliffs, NJ: Prentice-Hall. Shih, C. and Stankovic, LA. 1990. Distributed deadlock detection in Ada runtime environments. ACM S1GADA

Ti-Ada Conference. Stankovic, J. 1988. Misconceptions about real-time computing: a serious problem for next-generation systems.

IEEE Computer. 21. Wolfe, V., Davidson, S., and Lee, I. 1990. Supporting real-time concurrency. 7th Workshop on Real-time Operating

Systems and Software. Wolfe, V., Davidson, S., and Lee, I. 1991. RTC: language support for real-time concurrency. Real-Time Systems

S)Tnposium. IEEE Computer Society. Wolfe, V. 1991. Supporting Real-Time Concurrency. Ph.D. thesis, Department of Computer and Information Science,

University of Pennsylvania. Available as Technical Report MS-CIS-91-55.

Deadlock prevention in concurrent real-time systems

Documents

Transcript of Deadlock prevention in concurrent real-time systems