Resource Deadlock

Dr. Gertrude Levine Computer Science

Deadlock in Intersections
Consider gridlock in four one-way streets

Four necessary preconditions for this type of deadlock.

Coffman, Elphick and Shoshani [1]

1) Resources must be held in mutual exclusion

Termed serially reusable or shareable. We assume that if cars attempt to share an intersection space within the same interval of time, collision occurs. We also assume that collision is not acceptable.

Necessary preconditions for resource deadlock

2) Resources cannot be preempted. A resource cannot be taken away forcibly from a process that is holding it.
We assume that there is no crane available to lift up a car that is within the intersection. In computer systems, data are frequently protected by locks to ensure that they are used consistently. In resource deadlock, locks can be released only by their owners.
4

Necessary preconditions for resource deadlock

3) Processes hold (non-sharable, nonpreemptable) resources while waiting for others that they are requesting.
Cars do not release their street space unless they obtain the space in front. We assume no backing up or driving on the sidewalk.
Street space is continuous. Continuous resources are modeled by considering a car space as consisting of multiple discrete resource units.
5

Necessary preconditions for resource deadlock

4) The first 3 preconditions are inherent to the resource system. A resource deadlock only occurs if, in addition, there exists a circular chain of processes each of which is requesting a resource that is held by another process in the chain. (These four preconditions are necessary for all resource deadlocks.)
6

Wait-for (directed) graph

R.C. Holt [5]

Resource deadlock with two processes and two unique resources

P1 R2

R1 P2

Resource deadlock with fungible (interchangeable) resource units

o P1 R1 o P2

R2

P3
8

Resource deadlock with multiple-unit requests

What if processes can request multiple fungible resource units at the same time?
P1

R1

P2

P3 R2
The default weight for a request is 1. Process P1 needs 2 units simultaneously. One unit of R1 is available, but is of no value to P1. Although resource ordering would prevent this deadlock, it would not prevent all such resource deadlocks. For example, if all processes need 2 more units of R1 and P2 and P3 already have one unit, deadlock occurs.

Resource deadlock can be prevented

Negate the preconditions
1) Make resources concurrently shareable.
For example, read-only memory or files

2) Make resources preemptable

Direct cars into a parking lot; install back up resource Virtualize resources: CPU (with time-sharing), memory (with virtual memory). Preemption engenders a cost of context-switching and the repetition of resource acquisition
10

Prevent resource deadlock

3) Do not allow processes to wait for a resource while holding another resource
Schedule processes sequentially no concurrency Resource pre-allocation get all or none of needed resources
OS/360 required all resources to be allocated to programs before they were scheduled. Process waits are theoretically unbounded
Process with large resource needs, etc. may never be executed

Cars cannot move into an intersection unless the following space is empty. Do Not Block the Box. If the requested resource is not available, the waiting process releases all held resources.
Can try later, but again unbounded waits are possible. Heuristic if you are waiting too long, do a hard reboot
11

Prevent resource deadlock

4A. Prevent a circular chain of processes
Assume that resources are not created dynamically Require processes to request resources is a linear order (resources must be uniquely identifiable)
P1: asks for R1 then R2 P2: asks for R1 then R2 Resources must be statically and uniquely named. Programmers proper usage must be enforced by the system. But this mechanism is good where appropriate.
12

Prevent resource deadlock

4B. Prevent a circular chain of processes
1) Maintain a safe state- do not allocate resources unless the system has enough units available for processes to complete service (in some order). Processes must prestate needs. This mechanism works for unique units, interchangeable units, and multiple unit requests, but not if you allow processes to create dynamic resources. 2) Use a heuristic for interchangeable units. Do not accept new customers unless some percentage of resources are free (about 30%).
Some researchers classify safe states as deadlock avoidance rather then prevention, but clearly this mechanism addresses the fourth precondition for a resource deadlock with multiple interchangeable resource units or with multiple simultaneous requests.
13

Detection and recovery

Resource deadlock can be detected because of the circular wait.
If deadlock is rare and recovery is not too onerous, recovery might be preferable to prevention schemes.
The Java environment provides a deadlock detection routine. Dynamic objects are routine in the Java environment.

Recovery may be possible by reverting to a point before deadlock occurred and hoping that deadlock does not recur. Else choose a victim (this is a heuristic), kill it, and restart it after a pause.
May involve serious loss of work and other overhead.
14

Existing definitions of deadlock

a) An infinite waiting state containing a nonempty set of processes [5,15] b) An infinite waiting state containing a nonempty set of processes that cannot make any progress. (They might be active, but they cannot progress past a certain state.) [13] c) An inactive infinite waiting state containing a nonempty set of processes that cannot progress past a certain state. (as opposed to livelock) [8, 16] d) An infinite waiting state containing a nonempty circular chain of processes.
[7, 10]

e) An infinite waiting state containing a nonempty set of processes in a circular chain, such that each process is holding a non-shareable, nonpreemptable (unique) resource while waiting for a resource held by the next process in the chain. [1] f) An infinite waiting state containing a chain of processes, such that each process is waiting for one or more non-shareable, non-preemptable resources, of which a required number of units are held by other process(es) in the chain.
15

Deadlock examples
Holt [5] provides an example of a single process in deadlock: process Revenge is suspended waiting for an event that never occurs. Nutt [9] states that a kernel process is in deadlock if it is permanently blocked waiting for a resource that will never become available. No circular wait is specified. In accordance with the Halting Problem, these types of dead state are impossible, in general, to prevent.
16

Deadlock example
producer() { int item; while (TRUE) { produce_item (&item); /* If no slot is empty when down (mutex) is executed */ down (mutex); /* producer() holds the soft resource, mutex, and then */ down (empty); /* blocks on empty. producer() waits for consumer to signal that empty is available*/ enter_item (item); up (mutex); up (full); } } consumer () { int item; while (TRUE) { down (full); down (mutex); /* consumer() blocks, since mutex is locked by producer and cannot execute up (empty),*/ /* a cooperation mechanism. Note that consumer() is not holding empty. */ remove_item (&item); up (mutex); up (empty); consume_item (item); } } /* example from A. Tanenbaum [14. comments are mine*/

17

Deadlock Examples
Silberschatz et al. [11] claim that a deadlock exists if two trains on different tracks approach an intersection and wait for the other to proceed. Stallings [12] gives an example of four cars at different stop signs approaching an intersection, where each gives precedence to the car on its right. No cars or trains are holding resources requested by others.
18

Deadlock examples
Davis and Rajkumar [2] and Flynn and McHoes [4], cite a deadlock example of two programs issuing a seek command to reposition the access mechanism. Each is interrupted before executing its read command. When it then attempts to read it discovers that the other has moved the disk arm. Each then reissues the seek command in turn, but is again interrupted by the other. This sequence continually repeats. Processes are not blocked from resources, which are, indeed, repeatedly preempted.
19

Classification of dead states

Circular dead states
a circular chain (definition d)

General dead states

make no further progress (definition b or c depending on inactive or active (livelock)

Unacceptable waits
infinite waiting states (definition a)

Communication deadlocks Scheduling deadlocks Interleaved deadlocks Resource deadlock is a subset of this anomaly
Circular chain of processes each waiting for resources held by next/ other processes in the chain (definitions e and f)

Communication dead states Scheduling dead states Interleaved dead states

Communication unacceptable wait Scheduling unacceptable waits Interleaved unacceptable waits

20

Notes on Classification Scheme

Unacceptable waits are supersets of all dead states Cooperation mechanisms are misused in communication dead states. The dead processes need revision to complete service. Competition mechanisms are misused in scheduling and interleaved dead states. Scheduler is in error/ incomplete. Resource deadlock involves cooperation and competition mechanisms, but only the competition mechanisms are incorrect/ incomplete.
21

Communication deadlock
Infinite circular waits with cooperation errors
These circular waits involve at least two synchronous processes.
Examples: Tanenbaums producer/consumer [14], Holt [5] two processes that each request a resource of the other before the other has created it.

Communication deadlock cannot be prevented by pre-allocation of resources, resource ordering, safe states. Can be detected by circular wait, buy restart can not affect recovery.
22

Scheduling deadlocks
Infinite circular waits involving incomplete/incorrect competition mechanisms
Ex: 4 cars at the corners of an intersection with stop signs at each corner [12]; trains at intersection in [11]

Processes do not wait for resources held by others. Scheduling deadlock cannot be prevented by making resources preemptable or denying hold and wait precondition. (requested resource is available) Can be detected by circular wait. Although restart will probably affect recovery, more efficient recovery involves changing some rule temporarily without necessitating backup or repeat of service.
23

Interleaved deadlock
Resource deadlock is a subset of interleaved deadlock. Competing processes are asynchronous.
If resources are unique, a circular chain of processes holding resources is sufficient to define the deadlock If resources are interchangeable, all processes in the chain are waiting for resource unit(s) held by other processes in the set.

Processes can complete service if executed sequentially (assuming no other errors).

24

Communication dead states

(Superset of communication deadlock) Process error prevents any further progress, as well as that of all processes that require service from it. These processes may be inactive or active, perhaps spinning on a lock. (Some call the latter livelock.) Ex: Holts [5] process Revenge; Nutts kernel process [9] This class includes processes in infinite loops. Cannot generally be prevented or detected. Heuristics, based on time, are frequently used to kill a process.
25

Scheduling dead states

Deadlock or livelock caused by scheduling errors/ incompleteness.
Ex: Using resource pre-allocation, two Chinese philosophers can prevent a philosopher that is seated between them from eating. Incorrect routing protocols can lead to infinite cycles (message pingponging). Resource pre-allocation does not prevent this type of anomaly.
26

Interleaved dead states

Scheduler schedules processes in interleaved order to the required resources
Non-shareable resources are not locked; then data inconsistencies can occur. Resources are locked, but processes continuously release held resources and try again. [2, 4].

Linear orders and resource preemption will not prevent these dead states, but resource preallocation will.
27

Unacceptable communication waits

Cooperation mechanisms erroneously prevent event within required time period.
Dijkstras [3] incorrect (first) software solution to the critical section problem
Processes take turns by toggling flag after each is done. Second process goes out for a cup of coffee.

Obviously not a resource deadlock. Resource pre-allocation is not a solution.

28

Unacceptable scheduling waits

Scheduler assigns priorities incorrectly, causing unacceptable waits
Examples: priority inversion; circular routing during heavy traffic

If process does not complete service within its time constraint, it is dead and has an infinite wait

29

Unacceptable interleaved waits

Too many processes are accepted into a system, so that they interfere with each others service (their requests are interleaved in service) Continual preemption (discards, kill and restart, swapping) causes congestion/ page thrashing, etc. Most processes do not complete within their time constraints. Pre-allocation of resources prevents these dead states.
30

A model for defining deadlock

Layers for a resource system
Resource service layer, resource buffer layer, user buffer layer, and conception layer

Scheduling deadlock can be corrected in resource service layer (no loss of service)
dynamically change scheduling rules, priorities, etc.

Resource deadlock can be corrected in resource buffer layer by restarting one or more processes
Requires backups in the resource buffer layer

Communication deadlock requires abortion; reconception of erroneous process by its user

31

References
[1]]

E.G. Coffman, M. J. Elphick, and A. Shoshani, System Deadlocks, ACM Computing Surveys, vol. 3 , no. 2, pp. 67-78, June 1971. [2] W.S. Davis and T. M. Rajkumar, Operating Systems, A Systematic View, 5th ed., Addison-Wesley, Reading, Mass., p. 123, 2001. [3] E. W. Dijkstra, Cooperating Sequential Processes, Programming Languages, Academic Press, London, 1965. [4] I. M. Flynn and A. M. McHoes, Understanding Operating Systems, Brooks/Cole, Australia, pp. 109-110, 2001. [5] R.C. Holt, Some Deadlock Properties of Computer Systems, ACM Computing Surveys, vol. 4, no. 3, pp. 179-196, Sept. 1972. [6] D. Horner, Operating Systems, Concept and Applications, Scott, Foresman and Co. Glenville, Ill., pp.160, 105, 182, 1989. [7] W. S. Lai, Protocol Traps in Computer Networks- a Catalog. IEEE Transactions on Communications, Com-30, no. 6, pp. 1434 -1448, June 1982. [8] J.C. Mogul and K. K. Ramakrishnan, Eliminating Receive Livelock in an Interrupt-driven Kernel, ACM Trans. on Computer Systems, vol.15, no.3, pp. 217-252, Aug. 1997. [9] G. Nutt, Operating Systems, a Modern Perspective, 2nd edition, Addison-Wesley, Reading, Mass., pp.150, 279, 2000. [10] D. J. Rosenkrantz, R. E., Stearns, and P. M. Lewis, System Level Concurrency Control for Distributed Database Systems, ACM Trans. on Database Systems, vol.3, no.2, pp.178-198, June 1978. [11] A. Silberschatz, P. B. Galvin, and G. Gagne, Operating Systems Concepts, 6th edition, Addison-Wesley, Reading, Mass., pp. 204, 243, 244, 266, 2002. [12] W. Stallings, Operating Systems, Internals and Design Principles, 3rd edition, Prentice Hall, Englewood Hills, NJ, pp. 254, 1998. [13] A. Tanenbaum, Computer Networks, 4th edition, Prentice Hall, Upper Saddler River, NJ. 2003. [14) A. Tanenbaum, Operating Systems, Design and Implementation, 2nd edition, Prentice Hall, Upper Saddle River, NJ, pp. 6769, 1997. [15] D. Tsichritzis, and F. Lochovsky, Data Base Management Systems, Academic Press, London, p. 260, 1977. [16] R. J. Van Glabbeek, Notes on the Methodology of CCS and CSP, Theoretical Computer Science, pp. 329 - 349, 1997.

32