Chapter 7, Deadlocks

1. Chapter 7, Deadlocks

2. 7.1 System Model • In order to talk about deadlocks in a system, it’s helpful to have a model of the system • A system consists of a set of resources • The resources can be grouped into types • Processes compete to have (unique) access to instances of the types

3. Examples of resource types: • Memory locations • CPU cycles • Files • Object locks • I/O devices (printers, drives, etc.) • When classifying by type, each item has to be interchangeable • Otherwise, it’s necessary to classify into (distinct) subtypes

4. Each process can request (and hold) as many resources as needed to complete its work • Each process may request one or more instances of one or more types of resource • It makes no sense for a process to request more instances of resources than exist • Such a request can only be denied and such a process cannot do whatever it supposedly was intended to do

5. Request/Use sequence • Request the resource • This request will either be granted or not • If granted, use the resource • After use, release the resource • Note that “use” will involve a certain period of time when the process holds the resource

6. Request and release are forms of system calls • As usual, you may make explicit calls, or the compiler may generate them from your source code • Examples: • You can open and close files • You can request and release devices • You can allocate and de-allocate (free) memory locations

7. The O/S manages access to shared system resources • User level resource sharing may also be implemented in synchronized application code • The general plan of action for synchronization described in the previous chapter applies to system level resource management

8. Aspects of system resource management: • The O/S keeps a list of resources and records which have been allocated to which process • For processes that couldn’t acquire a resource, there is a separate waiting list for each resource • Processes’ statuses implicitly (due to the presence of their PCB in a waiting list) or explicitly (due to a value recorded in their PCB) reflect whether the processes have acquired or are waiting for certain resources

9. Definition of deadlock • Deadlock is a condition involving a set of processes (and a set of resources) • Verbal definition of deadlock: • Each process in the set of deadlocked processes is waiting for an event (namely, the release of a lock = the release of a resource) which can only be caused by another process in that set

10. Keep in mind the idea that you can have resources and you can have locks on the resources • Access to the resource is managed through access to or possession of the lock • This was the basis of the car/car title analogy • Hypothetically, access to resources could be granted directly, without some lock concept between the process and the resource • In that case, deadlock could literally occur on the resources

11. In practice, access to a resource is managed through a semaphore, a lock, or some other control mechanism • As a consequence, deadlocking typically occurs on the stand-in, the lock or other mechanism, not on the resource itself

12. Under correct synchronization, deadlock should not be possible on one resource • Either one process has it or another does • The process that doesn’t is simply waiting for it to be released by the other process, without any other conditions being attached

13. Deadlock can occur with as few as two contending processes and two shared resources • Deadlocks can occur on instances of one kind of resource type or instances of various kinds of resource type • The number of processes and resources involved in a deadlock can be arbitrarily large

14. As a student, the place you are most likely to concretely encounter deadlock is in Java thread programming • Although it doesn’t necessarily use the term “lock”, mutual exclusion meets the requirements for a process action that has the effect of a lock. • Mutual exclusion means that one thread locks another out of a critical section

15. As soon as you have threads, you have the potential for shared resources—and a critical section itself can qualify as the shared resource • As soon as you have shared resources, you have to do synchronization so that your code is thread safe • As soon as you write code with synchronization, assuming >1 process and >1 resource, you have the potential for deadlock

16. 7.2 Deadlock Characterization • Necessary conditions for deadlock: • 1. Mutual exclusion (locking): There are common resources that can’t be shared without concurrency control • 2. Hold and wait: Once processes have acquired resources (locks) they’re allowed to hold them while waiting for others

17. 3. No pre-emption: Resources can’t be pre-empted (swiped from other processes). • A process can only release its resources voluntarily • 4. Circular wait: This condition is actually redundant. • The previous three conditions imply this one, which is essentially a complete statement of the underlying problem:

18. This is a summary of the deadlock conditions: • If processes can’t acquire resources, they wait. • If process x is waiting for a resource held by process y and y is waiting for a resource held by x, this is circular wait • It turns out that it’s relatively easy to understand deadlocks by looking at diagrams of them

19. Resource allocation graphs • Let processes, Pi, be represented as circles (labeled) • Let resources, Ri, be represented as boxes with a dot for each instance of the type • Let a request by a process for a resource be represented by an arrow from the process to the resource • Let the granting of requests, if successful, be immediate. • Such an arrow will only be shown in cases where the request could not be granted

20. Let the granting of requests also be atomic • Let the granting, or assignment, of a resource to a process be represented by an arrow from the resource to the process • If there is more than one instance of the resource, the arrow should go from the specific dot representing that instance • Illustrations follow

21. Pi requesting and being granted an instance of Rj

22. A cycle in the resource allocation graph implies a deadlock • A cycle in a directed graph is not simply a connected path through the graph • It’s a path where all of the arrows point in the same direction • A diagram of the simple, classical case follows

24. The book’s next example includes multiple resource types and multiple processes • It also includes multiple dots per box, representing multiple instances of a resource • This principle holds: If there is no cycle in the graph, there is no deadlock • The example shows waiting, but no deadlock • A diagram follows

26. Whether there is more than one instance of a resource type or not, no cycleno deadlock • However, with more than one instance of a resource type, even if there is a cycle in the graph, there may or may not be deadlock • The next example illustrates a case with deadlock

28. The next example illustrates a case where there is a cycle in the resource allocation graph, but there is no deadlock • A verbal description of the situation is given next—but it can essentially be skipped • The lack of a deadlock should be apparent from the diagram which follows

29. There is no deadlock because, of the multiple instances of resource R1 which are held, one is held by P2, which is not in the cycle. • Similarly, one instance of R2 is held by P4, which is not in the cycle • If P2 gives up R1, R1 will immediately be assigned to P1, and the cycle in the graph will disappear. • Likewise, if P4 gives up R2, R2 will immediately be assigned to P3, and the cycle in the graph will disappear

31. 7.3 Methods for Handling Deadlocks • There are three major approaches to deadlock handling which lead to subsections in the book • 1. Use techniques so that a system never enters the deadlocked state • A. Deadlock prevention • B. Deadlock avoidance • 2. Allow systems to deadlock, but support: • A. Deadlock detection • B. Deadlock recovery

32. 3. Ignore the problem—in effect, implement processing without regard to deadlocks • If problems occur (system performance slows, processing comes to a halt) deal with them on a special case basis • The justification for this is that formal deadlock may occur rarely—and there are other reasons that systems go down • Administrative tools have to exist to re-initiate processing in any case. • Deadlock is just one of several different cases where they are necessary

33. In extreme cases, rebooting the system may be the solution • Consider these observations: • How many times a year, on average, do you press CTRL+ALT+DEL on a Windows based system? • Hypothesize that in a given environment, one formal deadlock a year would occur • Under these circumstances, would it be worthwhile to implement a separate deadlock handling mechanism?

34. In the interests of fairness, note this: • In fact, in simple implementations of Unix, what has been described is the level of support implemented for deadlock handling • It may not be elegant, but it’s easy to reboot, and suitable for simple systems

35. Deadlock handling in Java • The book’s explanation may leave something to be desired • The book’s example program is so confusing that I will not pursue it • In short, although a fair amount of Java synchronization was covered in the last chapter, I will be limiting myself to the general discussion of deadlock handling in this chapter

36. The situation can be summarized in this way: • Java doesn’t contain any specific deadlock handling mechanisms • If threaded code may be prone to deadlocking, then it’s up to the application programmer to devise the deadlock handling

37. It is worth keeping in mind that the Java API contains these methods, which apply to threads, and have been deprecated: • suspend(), resume(), and stop() • Part of the reason for deprecating them is that they have characteristics which impinge on deadlock

38. The suspend() method causes the currently running thread to be suspended, but the suspended thread will continue to hold all locks it has acquired • The resume() method causes a thread to start again, but this call to resume can only be made in some other, running thread • If the suspended thread holds locks required by the other thread which contains the call to resume the suspended thread, deadlock will result

39. The stop() method isn’t directly deadlock prone • As pointed out some time ago, it is prone to lead to inconsistent state • Consider this typical sequence of events: • Acquire a lock • Access a shared data structure • Release the lock

40. When stop() is called, all locks held by the thread are immediately released • In confused code, stop() could be called at a point where a shared resource has undergone incomplete modification • In other words, the call to stop() will cause locks to be released before the point where they should be • This can lead to inconsistent state

41. It may seem odd that a programmer would call stop() somewhere during the modification of a shared resource, but • Hamlet:...There are more things in heaven and earth, Horatio,Than are dreamt of in your philosophy.Hamlet Act 1, scene 5, 159–167

42. In short • In Java, it’s the programmer’s problem to write code that isn’t deadlock prone • There are definitely things in the Java API to avoid if you are worried about deadlock • The book’s example program is not the ideal vehicle for seeing how to solve this as a programmer • I don’t have the time to dream up a better example • …

43. 7.4 Deadlock Prevention • Recall the preconditions for deadlock: • 1. Mutual exclusion (locking) • 2. Hold and wait • 3. No pre-emption • 4. Circular wait (redundant) • The basic idea behind deadlock prevention is to implement a protocol (write code) where at least one of the preconditions can’t hold or is disallowed

44. 1. Disallowing mutual exclusion • This is not an option • It’s true that without mutual exclusion, deadlock is impossible, but this consists solely of wishing the problem away • The whole point of the last chapter was the fact that in some cases mutual exclusion is necessary, and it is therefore necessary to be able to manage the deadlock that comes along with it

45. In support of the need for mutual exclusion, the book finally gives a rock-bottom simple example of a shared resource managed by the O/S where mutual exclusion is necessary: • Having given the printer to one process, it is out of the question to interrupt it and hand the resource over to another process in the middle of a print job

46. 2. Disallowing hold and wait • This is doable • There are two basic approaches: • A. Request (and acquire) all needed resources before proceeding to execute • B. Only request needed resource(s) at a point when no others are held

47. Both option A and option B are kinds of block acquisition. • B is a finer grained version of it than A—a single process may request and release >1 block of resources over time • Note that “wait” in the phrase “hold and wait” means wait for other needed resources to become available

48. Problems with disallowing hold and wait: • Low resource utilization—because processes grab and hold everything they need, even when they’re not using it • If B is impractical, A is forced, but A is the more drastic choice where more unused resources are held for longer times • Starvation is possible if a process needs a large set of resources and has to be able to acquire them all at the same time

49. In general, the underlying goal of a multi-tasking system is concurrency. • Disallowing hold and wait reduces concurrency • Processes that aren’t deadlocked may not be able to run because they require a resource another process is holding but not using • Note that disallowing hold and wait is not practical in Java. • Java doesn’t have a block request mechanism

50. 3. Disallowing no pre-emption • Implement a protocol which allows one process to take locks/resources away from other processes as needed • There are two approaches, given below