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

33

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

39

40

• The next example illustrates a case with deadlock

41

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

44

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)

51

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

• This section will mention deadlock handling in Java without going into concrete detail

• It will then go on to a general discussion of the three approaches to dealing with deadlock

52

• The situation in Java 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

53

• 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

54

• The suspend() method causes the currently running thread to be suspended

• Even though it’s suspended, it will continue to hold all the locks it has acquired

• Compare this to a call to wait(), where the thread is placed outside of the monitor

• It can’t hold a lock on the critical section if it’s outside the monitor

55

• 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

56

• The stop() method isn’t directly deadlock prone

• As pointed out some time ago, it is simply prone to lead to inconsistent state

57

• Consider this typical sequence of events:– Acquire a lock– Access a shared data structure– Release the lock

• When stop() is called, all locks held by the thread are immediately released

58

• 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

• Compare this with a call to interrupt()• If a thread is interrupted, it is allowed to do

housekeeping before it finally quits

59

• 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

60

• 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• In particular, keep in mind that your code will

be problem-prone if you use calls to the methods suspend(), resume(), or stop()

61

• 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

• Therefore, I won’t claim to have told you how to do this correctly

• You’ll have to settle for the warning about how not to do it incorrectly

62

7.4 Deadlock Prevention

• The first of the three major approaches to handling deadlock was to implement synchronization protocols so that deadlock can’t happen

• The first of the two sub-approaches under this heading was deadlock prevention

63

• Recall the preconditions for deadlock:• 1. Mutual exclusion (locking)• 2. Hold and wait• 3. No pre-emption• 4. Circular wait (redundant)

64

• 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

• That means that in theory there can be a deadlock prevention implementation based on each of the different preconditions

65

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

66

• 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

67

2. Disallowing hold and wait

• This is doable• There are two basic approaches:– A. Request (and acquire) all needed resources

before proceeding to execute—in other words, acquire up front

– B. Only request needed resource(s) at a point when no others are held—in other words, acquire as you go, but only at “safe” points

68

• 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

69

Problems with disallowing hold and wait:

• Low resource utilization—because processes have to 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

70

• 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

71

• Note that disallowing hold and wait is not very practical in Java.

• Java doesn’t have syntax for simultaneous block acquisition of a group of resources

• In user code, it might be possible to group acquisition requests for multiple resources together in one critical section

• However, trying to implement deadlock prevention in this way in application code would probably be problematic

72

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

73

• 1. Self-pre-emption: The requesting process gives up resources– If process P holds resources and requests

something that’s unavailable because it’s held (by process Q, for example), process P releases the resources it has already acquired

– Process P will have to start over from scratch

74

• 2. External pre-emption: The requesting process takes resources– If process P requests something that’s unavailable

because it’s held by process Q, and process Q in turn is also waiting for resources, then process Q is required to release its resources and process P takes what it needs

– In this case, process Q was pre-empted and will have to start over from scratch

– If process Q is active, not waiting, when P makes its request, then pre-emption will not occur and P will have to wait

75

• Note that pre-emption based deadlock protocols are related in nature to pre-emptive scheduling and context switching

• The CPU itself is a resource shared among processes

• Registers and other system components are examples of specific parts of this resource

• One process can interrupt, or pre-empt another, and take the shared resource

76

• In any pre-emption based system, the critical point is that whatever is pre-empted has to be left in a consistent state

• Context switching can be made to work because the state of the pre-empted process can be saved and restored

• Pre-emption to deal with deadlock also has to concern itself with maintaining consistent state

77

• In the verbal description of the deadlock algorithms, the statement was made that pre-empted processes would have to start from scratch

• That didn’t mean that users would have to resubmit them

• It meant that the system would keep a record of the resources they had requested, and when they were scheduled again, the first order of business would be re-acquiring those resources

78

• Keep in mind that in some cases, pre-emption is simply not a practical option.

• A simple, concrete example would be acquisition of a printer.

• If a process has already acquired a printer, it should not give it up until it’s finished with it

• Chaos results if the printed output consists of interleaved print jobs

79

• The reality is that there is more to pre-emption than meets the eye.

• The critical question when pre-empting is whether or not the pre-empted process already accomplished some work

• This is connected with the concept of atomicity

80

• The internal logic of a transaction may require that various sub-parts of it be executed together, all or nothing

• Translated into the terminology of locks, this would mean that the transaction would have to hold the locks for the sub-parts simultaneously, not sequentially

81

• If deadlock prevention involved pre-emption, it would be necessary to make sure that the pre-emption didn’t interrupt the atomic transaction

• In other words, if there are interdependent locked resources, if the transaction has accessed one resource, it can’t give up its locks until it’s accessed the other resource

82

4. Disallowing circular wait

• Although “circular wait” is in a sense redundant, it encapsulates the idea behind deadlock and it suggests a solution– 1. Number the resource types– 2. Only let processes acquire items of types in

increasing resource type order– 3. A process has to request all items of a given

type at the same time

83

• Why does this work?• Examine the classic case of deadlock, and

observe how it doesn’t meet the requirements listed above:

84

85

• The order of actions for P1:– Acquire R1– Request R2

• The order of actions for P2:– Acquire R2– Request R1

• P2 did not acquire/try to acquire resources in ascending order by type

86

• If all processes acquire in ascending order, waiting may result, but deadlock can’t result

• This is the verbal explanation– Suppose process 1 holds resources a, b, c, and

requests resource x– Suppose process 2 holds x– Process 1 will have to wait for process 2

87

– However, if process 2 already holds x, because it acquires in ascending order, it cannot be waiting for resources a, b, or c

– It may already have acquired copies of those resources that it needs, or it may not need them at all, but it will not be going back to try and get them

– Therefore, it is not possible for process 1 and process 2 to be deadlocked

88

• A variation on the previous idea• Suppose a process reaches an execution point

where it becomes clear that a resource with a smaller number is now needed

• The process will have to release all resources numbered higher than that one and acquire them again—in ascending order

• This is obviously costly

89

7.5 Deadlock avoidance

• The first of the three major approaches to handling deadlock was to implement synchronization protocols so that deadlock can’t happen

• The first of the two sub-approaches under this heading, deadlock prevention, was just covered

• It worked by disallowing one of the preconditions for deadlock

• Deadlock prevention is essentially a technique that reduces concurrency

90

• The second of the two sub-approaches under this heading of making sure that deadlock doesn’t happen is deadlock avoidance

• Deadlock avoidance is based on having more information about resource requests by processes

• With sufficient knowledge, requests may be ordered/granted in a way that will not lead to deadlock

91

• Deadlock avoidance potentially solves the deadlock problem while still allowing high levels of concurrency

• Under simple deadlock prevention, processes have to acquire all of their resources up front.

• Under simple deadlock avoidance, processes have to declare all of their resource needs up front

• The protocol then works from there

92

Deadlock avoidance and safe states

• In order to formally define a deadlock avoidance algorithm, it’s necessary to define a safe state

• Informally, a safe state is a situation where granting a resource to a process will not cause deadlock

• Conversely, an unsafe state is one where granting a resource to a process would cause a deadlock

93

• It’s worthwhile to keep in mind that we’re worried about safe states under the condition that some resources are already held by some processes

• If no processes hold any resources, granting a resource could not lead to an unsafe state

94

• Informally, deadlock prevention algorithms prevent a system from entering a deadlocked state

• Deadlock avoidance is one step removed from that

• Under deadlock avoidance, a system is not allowed to enter an unsafe state

95

• Under deadlock avoidance a system is not allowed to enter a state where it would be dangerous to grant a resource because granting it would cause deadlock

• Under a deadlock avoidance algorithm the system moves only from one safe state to another, always avoiding the possibility of deadlock

96

Definitions needed for deadlock to discuss deadlock avoidance in detail

• In order to formally define a safe state, it’s necessary to define a safe sequence

• A sequence refers to a numbered set of processes, which can be shown using this notation:

• <P1, P2, …, Pn> • A safe sequence has this property:• For all Pj, Pj’s resource requests can be satisfied by

free resources or resources held by Pi, where i < j.

97

• Safe state:• Formal definition: A system is in a safe state if

there exists a safe sequence• Informal definition: A system is in a safe state if

it can allocate resources to processes in some order without deadlock

• Practical consequence: The goal, then, is to find a safe sequence, and allocate resources in sequence order

98

• You don’t necessarily identify the safe sequence all at once

• A deadlock avoidance protocol can be regarded as an iterative process

• A resource is granted to a process under the condition that the resulting state is safe

• Then the next resource can be granted to a process under the same condition

• The iteration continues

99

• As long as the safe state condition can be met each time a resource is granted, eventually all requests will be met

• In the course of granting resources, the system will have moved from one safe state to another

• There may be many different possible paths through the iteration, which would go through different safe states

• What’s important is that at least one series of safe states can be found

100

• Notice how deadlock avoidance is related to the idea of circular wait

• Under the definition given for a safe sequence of processes, a process Pj can be waiting, but only on Pi where i < j

• Pj can’t be waiting on some Pk where k > j

101

• More specifically, Pi can’t be waiting on Pj

• Waiting, or dependency, only goes in sequential order, ascending by subscript

• As a consequence, there can be no circular waiting in a safe sequence

102

• If there is no circular waiting, then it would be possible to grant a resource to one of the processes without causing deadlock

• Deadlock avoidance says, additionally, that you can only grant the resource if the result is a state which is also safe

• If so, then the granting of resources can continue indefinitely

103

• Five observations can be made based on these definitions:

• 1. Certainly, a safe state is not deadlocked• 2. Also, granting a resource in a safe state

cannot result immediately in deadlock• 3. Incidentally, a deadlocked state is not safe

104

• 4. There are unsafe states that are not yet deadlocked, but the granting of a resource from such a state would result in deadlock

• 5. When in a safe state, the goal is to avoid granting a resource in such a way that the system goes into an unsafe state

105

• This is a scenario that illustrates an unsafe state:

• Pi has requested/is waiting for Pj

• This is unsafe, because it is a “forward” wait• Pj hasn’t yet made a request on Pi

• If it did, it would be a legal request• But in the presence of the pre-existing forward

wait, it would cause deadlock

106

• Under deadlock prevention, you avoid going into a deadlocked state

• Under deadlock avoidance, you want to avoid going into an unsafe state

107

• Allocations of currently free resources can cause a system to move from a safe to an unsafe state

• Because processes pre-declare their needs, an unsafe state (leading to possible deadlock) can be foreseen based on other requests and allocations that will be made

108

• There are several algorithms for deadlock avoidance

• They all prevent a system from entering an unsafe state

• The algorithms are based on pre-declaration of needs, but not immediate acquisition of all resources up front

109

• Like deadlock prevention algorithms, deadlock avoidance algorithms tend to have the effect of reducing concurrency

• Their level of concurrency reduction is low because not all resource acquisitions have to happen up front

110

Resource allocation graph algorithm for deadlock avoidance

• Let the previous explanation of the resource allocation graph stand:– Let a request by a process for a resource be

represented by an arrow from the process to the resource

– When a request is made, it may be granted or not, but if it is, the granting is atomic

– Let the granting, or assignment, of a resource to a process be represented by an arrow from the resource to the process

111

• For deadlock avoidance, let a new kind of edge, a claim edge, be added to the notation– A claim edge goes in the same direction as a

request, but it’s dashed– A claim edge represents a future request that will

be made by a process

112

• The resource allocation graph algorithm says:– Requests for resources can only be granted if they

don’t lead to cycles in the graph– When identifying cycles, the dashed claim edges

are included– The point is that a cycle in the graph now indicates

an unsafe state

113

• What follows is a sequence of diagrams showing two processes progressing towards an unsafe state

• The initial diagram only shows claim edges. • These are the pre-declared requests of the

processes• The claim edges are converted into request and

grant edges as processing progresses• The last request can’t be granted because it would

lead to an unsafe state

114

• 1. All future requests are predeclared• 2.A. P1 requests R1• 2.B. P1 is granted R1

115

• 3. P2 requests R1. P2 is not granted R1• 4.A. P2 requests R2• 4.B. P2 is granted R2.

116

• The last state contains a cycle.• It is unsafe.• From that state, if R1 then requested R2

before anything was released, deadlock would result.

• You can’t enter a state from which you could enter deadlock.

117

• State 3 is the last safe state. • Therefore, under deadlock avoidance P2’s

request for R2 can’t be granted• The system can’t go from state 4.A to 4.B,

even though 4.B is not deadlocked.• Remember, 4.A and 4.B are atomic• The request would be made and rejected, and

the system would remain in state 3

118

Aspects of the resource allocation graph algorithm for deadlock avoidance

• This algorithm is based on pre-declaring all claims

• The pre-declaration requirement can be relaxed by accepting new claims if all of a process’s edges are still only claims

119

• Implementing a deadlock avoidance algorithm would require the implementation of a cycle detection algorithm in the resource allocation graph.

• The authors say this is within reason because such an algorithm has order of complexity O(n2)

120

The banker’s algorithm

• The resource allocation graph algorithm doesn’t handle multiple instances of each resource type

• The banker’s algorithm does• This algorithm is as exciting as its name would

imply

121

• The banker’s algorithm basically consists of a bunch of bookkeeping, using matrices to manage the granting of multiple resources to multiple processes

• It’s messy to do, but there is nothing cosmic about the idea

• I’m not covering it

122

7.6 Deadlock Detection

• The second of the three major approaches to handling deadlock was to implement synchronization protocols so that deadlock can be fixed if it does happen

• If you don’t do deadlock prevention or deadlock avoidance, then you allow deadlocks

123

• At this point, if you choose to handle deadlocks, two capabilities are necessary:– 1. Deadlock detection– 2. Deadlock recovery

• This is distinct from the third major approach, simply ignoring deadlocks, which will be discussed after this section

124

Detecting deadlocks with single instances of resource types

• The first thing you need is the ability to detect deadlocks in a system

• This can be done with a wait-for-graph• This is like a resource allocation graph, but it’s

not necessary to record the resources• Concretely, the O/S, in addition to its other

features, would be maintaining the wait-for-graph as one of the system resources, keeping it up to date as resources are granted to processes

125

• The key information in a wait-for-graph is whether one process is waiting on another

• A cycle in the graph still indicates deadlock• A simple illustration of a resource allocation

graph and a comparable wait-for-graph is given on the following overhead

126

127

• Wait-for-graph (WFG) algorithm implementation

• 1. The system maintains a WFG, adding and removing edges with requests and releases

• 2. The system periodically searches the graph for cycles. – This is O(n2), where n is the number of vertices

128

Several instances of a resource type

• This is analogous to the banker’s algorithm• Instead of a WFG, it’s necessary to maintain

some NxM data structures and algorithms• I am uninterested in the details

129

Deadlock detection algorithm usage

• When should deadlock detection be invoked?• This depends on two questions:– 1. How often is deadlock likely to occur?– 2. How many processes are likely to be involved?

• The general answer is, the more likely you are to have deadlock, and the worse it’s likely to be, the more often you should check

130

• Checking for deadlock is a trade-off• Checking isn’t computationally cheap• Checking the complete WFG every time a

resource request can’t be satisfied would be the greatest possible frequency for checking it.

• This would be extreme

131

• However, in a real system deadlock might be a significant problem which happens relatively frequently.

• It would not be wise to check for deadlock too infrequently.

• A system administrator might have a historical record of the frequency of deadlocks.

• It might be advisable to check for deadlocks on a schedule more frequent than the historical record.

132

• Overall, deadlock will tend to affect system performance because deadlock will prevent processes from proceeding

• In practice, deadlock detection might be triggered when some performance parameter falls below a certain value, for example, CPU utilization < 40%

• The system might be coded to do this automatically, or this might be something that the administrator does on a special case basis

133

7.7 Recovery from Deadlock

• Just like deadlock detection, deadlock recovery may be an automatic feature built into a deadlock handling system

• It may also be manual, done using system utilities on a special case basis by the administrator

134

• Overall, deadlock recovery falls into two possible categories:– 1. Abort processes to break cycles in the WFG– 2. Pre-empt resources from processes to break

cycles without aborting

135

Process termination (abortion)

• There are basically two approaches:– 1. Abort all deadlocked processes.– 2. Abort one process at a time among those that

are deadlocked• Approach 1 has the disadvantage that it

wastes a lot of work that was already done

136

• Approach 2 also has disadvantages– The underlying problem is that there may be >1 cycle– The cycles may be independent or they may share

processes– In any case, killing a single process may not break all

cycles in the system– If one process at a time is aborted, deadlock

detection will have to be done after each abortion to see whether the system is deadlock free

137

• The overall problem with abortion is the potential for leaving resources in an inconsistent state

• If abortion is supported, then all changes made by a process should be individually logged

• Then if a partially finished process is aborted, an advanced system will roll back all of the changes that the process had made

• That is, abortion isn’t complete until there is no trace of the process’s existence left

138

• Aside from the general question of rollback, if selective abortion is done under approach 2, then there need to be criteria for picking a victim.

• Examples of criteria for picking victims:– Process priority– Time already spent computing, time remaining (%

completion)

139

• Process abortion criteria, continued:– What resources are held– How many more resources are needed? (%

completion as measured by resources)– How many other processes will need to be

terminated?– Whether the process is interactive or batch…

140

Resource pre-emption instead of full abortion

• This is an even finer scalpel than abortion • Three questions exist for pre-emption that are

essentially the same as for abortion:• 1. Victim selection:– How do you choose a victim for pre-emption

(what cost function)?

141

• 2. Rollback: – In what way can you bring a partially finished

process back to a safe state where it could be restarted and would run to completion correctly, short of aborting it altogether?

• 3. Starvation: – How do you make sure a single process isn’t

repeatedly pre-empted?

142

The third major approach

• The third of the three major approaches to handling deadlock was to not implement any particular protocols to handle deadlock

• Just ignore it• If system performance tanks, you may or may not

suspect that deadlocks are to blame.• In any case, without any better system tools, the

gross solution to the problem would just be a restart.

143

The general topic of deadlock—again

• Consider the general principle illustrated by deadlock

• The problem, deadlock, arises due to concurrency

• The mindless “solution” to the problem is to eliminate concurrency

144

• It is not possible to implement an operating system without some form of concurrency control.

• Therefore, deadlock is an inescapable problem.

• The spectrum of solution approaches ranges from ignoring it, to detecting and recovering from it, to preventing it, to avoiding it

145

• The simplest way to deal with deadlock is to ignore it.

• The hope is that deadlock is infrequent.• If it does occur, whether you recognize it or

not, you overcome it by gross means, such as rebooting

146

• Other solutions are more fine-grained, each having its own implementation problems to solve

• With detection and recovery you have to maintain a graph and algorithms for detecting cycles in it.

147

• With detection and recovery, you also have to decide how fine-grained the recovery mechanism is.

• How do you choose victims for abortion?• Can rollback be implemented?• Is it possible to pre-empt at the level of

individual resources rather than whole processes?

148

• Rather than allowing deadlock to happen, you can do deadlock prevention.

• This disallows one of the necessary conditions for deadlock

• It severely affects concurrency

149

• One step further removed from deadlock prevention is deadlock avoidance.

• Deadlock avoidance depends on not entering an unsafe state

• This requires the maintenance and checking of a graph when granting resources

• It trades greater implementation complexity for a higher degree of concurrency

150

• This spectrum of implementation choices is broad• As usual, choosing a solution involves a trade-off• There is a cost to coding any given solution into the

operating system• There is also a certain level of performance that any

given solution might give• For any given system, with a certain kind of workload

and certain user expectations, the goal is to implement a cost-effective solution to the deadlock problem

151

The End