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

4. When classifying by type, each item has to be interchangeable • Otherwise, it’s necessary to classify into (distinct) subtypes

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

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

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

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

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

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

11. In other words, the system records process status both implicitly and explicitly • If a process’s PCB is in a waiting list for a given resource, its status relative to that resource is clear • If some resource relevant piece of information is recorded in a process’s PCB, its status relative to that resource is clear

12. Deadlock • Deadlock is a condition involving a set of processes and a set of resources • It is the processes that are referred to as being deadlocked • Resources are not referred to as being deadlocked • It is contention for the resources by the processes that causes the processes to become deadlocked

13. Definition of deadlock • Verbal definition of deadlock: • Each process in the set of deadlocked processes is waiting for an event which can only be caused by another process in that set • The event being waited for is the release of a resource • More specifically, the event being waited for is the release of a lock on a resource

14. There is a slight distinction between holding resources and holding locks on the resources • Access to the resource is managed through access to or possession of the lock • Cars and car titles provide an analogy • If you hold the title, then you own the car • The title, or lock, is a stand-in for the car, or resource, for the purpose of ownership/access protocols

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

16. In practice, access to a resource is managed through a semaphore, a lock, or some other control mechanism • As a consequence, in an implementation of an access protocol, deadlock typically occurs on the stand-in, the lock or other mechanism, not on the resource itself

17. Characteristics of deadlock • 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 • If there are no other resources under contention, then no other conditions can apply to the release and acquisition of the resource

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

19. The place you are most likely to concretely encounter deadlock is in Java thread programming • 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 • Under the covers Java synchronization is in fact managed by an object’s inherited lock

20. If an application has >1 thread, there is the potential for sharing resources among the threads • A critical section itself can qualify as the shared resource • If an application has shared resources, then synchronization is necessary so that the code is thread safe • Synchronized code with >1 thread and >1 resource has the potential for deadlock

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

22. 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 what deadlock is

23. A summary of deadlock • 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

24. Resource allocation graphs • It turns out that it’s relatively easy to understand deadlocks by looking at diagrams of them • Processes, Pi, can be represented as circles (labeled) • Groups of equivalent resources, Ri, can be represented as boxes • If there is more than one instance of a type, let it be represented by a dot in the box

25. 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. • A request arrow will only be shown in cases where the request could not be granted • Stated more precisely, the arrow represents a request that has not yet been granted

26. Let the granting of requests also be atomic, as well as immediate • If a request is made, it is either granted or not granted • The granting can’t be interrupted • A request can’t hang in an indeterminate state

27. Suppose that a resource request is granted • The assignment of a resource to a process is 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

28. A graph that uses the foregoing conventions is known as a resource allocation graph. • Illustrations follow

29. Pi requesting and being granted an instance of Rj

30. Graphical definition of deadlock • A graph is a structure consisting of nodes and arcs that connect them • A graph may be directed or undirected • In an undirected graph, the arcs do not have a direction • A cycle in an undirected graph is simply a connected path through the graph

31. A resource allocation graph is a directed graph • Its nodes are connected with arrows, which have a direction • A cycle in a directed graph is a connected path where all the arrows point in the same direction

32. If there is only one instance of each kind of resource type, the following statement holds: • A cycle in the resource allocation graph implies a deadlock • A diagram of the simple, classical case follows

34. Non-graphical notation • Resource allocation graphs can be represented using set notation • You can probably expect at least one test question where the set-up is given using set notation and you have to draw the graph • Or possibly, a scenario would be given using set notation and you would be asked if there was deadlock • To answer the question, you would most likely draw the graph for yourself

35. Using the book’s conventions, the processes are represented as P, the resources as R, and the arcs, or edges, connecting them, as E • The previously given graph could be summarized in this way: • P = {P1, P2} • R = {R1, R2} • E = {R1 → P1, P1 → R2, R2 → P2, P2 → R1}

36. Waiting, but without deadlock • 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 • 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

37. However, this principle holds, whether there is more than one instance of a resource type or not: • If there is no cycle in the graph, there is no deadlock • In other words, if you want to talk like a mathematician, a cycle is a necessary, but not sufficient condition for a deadlock in a general resource allocation graph

38. A resource allocation graph illustrating the example is given on the next overhead • The graph does not include a cycle • If you analyzed it, you might determine that certain processes may have to wait for other processes to finish with resources • But deadlock will not occur

40. The next example illustrates a case with deadlock

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

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

45. 7.3 Methods for Handling Deadlocks • There are three major approaches to deadlock handling • 1. Implement synchronization protocols so that deadlock can’t happen • 2. Implement synchronization protocols so that deadlock can be fixed if it does happen • 3. Do not implement any particular protocols to handle deadlock; ignore it

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

47. 3. Ignore the problem—in effect, implement processing without regard to deadlocks • System problems may occur • These might be high waiting times/slow performance/no progress • These may be the result of deadlocked processes • If they do occur, deal with them on a special case basis

48. 3. Continued—justification: • There are many reasons why systems go down • Administrative tools have to exist to re-start processing in any case. • Deadlock may only occur rarely • If it does, it can be handled as a special case requiring the use of the system re-start tools • In a simple case, rebooting may be the system re-start tool that is available

49. Consider these observations: • How many times a year, on average, do you press CTRL+ALT+DEL on a Windows based system? • Luckily, it is much less frequent now than it was before • Hypothesize that in a given environment, the need to do this due to deadlock would occur once a year • Under these circumstances, would it be worthwhile to implement a separate deadlock handling mechanism?

50. This discussion doesn’t just apply to Windows based systems. • Simple implementations of Unix do not have any special deadlock handling mechanism • It may not be elegant, but it’s easy to reboot, and suitable for systems without high performance expectations (like round-the-clock availability)