Resource Deadlock

1. Resource Deadlock Dr. Gertrude Levine Computer Science

2. Deadlock in Intersections Consider gridlock in four one-way streets

3. Four necessary preconditions for this type of deadlock. Coffman, Elphick and Shoshani [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.

4. 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.

5. Necessary preconditions for “resource” deadlock 3) Processes hold (non-sharable, non-preemptable) 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.

6. 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.)

7. Wait-for (directed) graph R.C. Holt [5] Resource deadlock with two processes and two unique resources P1 R1 R2 P2

8. Resource deadlock with fungible (interchangeable) resource units o P1 R1 o P2 R2 P3

9. P2 P1 2 • R1 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 with multiple-unit requests • What if processes can request multiple fungible resource units at the same time?

10. 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

11. 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

12. 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. Programmer’s proper usage must be enforced by the system. But this mechanism is good where appropriate.

13. 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.

14. 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.

15. 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, non-preemptable (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.

16. “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.

17. “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*/

18. “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.

19. “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.

20. Classification of dead states

21. 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.

22. Communication deadlock • Infinite circular waits with cooperation errors • These circular waits involve at least two synchronous processes. • Examples: Tanenbaum’s 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.

23. 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.

24. 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).

25. 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: Holt’s [5] process Revenge; Nutt’s 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.

26. 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 ping-ponging). • Resource pre-allocation does not prevent this type of anomaly.

27. 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 pre-allocation will.

28. Unacceptable communication waits • Cooperation mechanisms erroneously prevent event within required time period. • Dijkstra’s [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.

29. 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

30. Unacceptable interleaved waits • Too many processes are accepted into a system, so that they interfere with each other’s 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.

31. 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

32. 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 ComputingSurveys, 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. 67-69, 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.