Deadlock

• We have learned some examples

– Dining philosopher
– Two-phase locking

• In this lecture, we will study it systematically.

 Deadlock & starvation: definitions
• Deadlock occurs when a set of processes is blocked
waiting on requests for resources that can never be
satisfied
– while holding some resources, the processes request other
resources held by processes in the same set
– i.e. there is a notion of circular wait
• Starvation occurs when a process waits for a resource
that continually becomes available but is never
assigned to it for priority reasons or for a design flaw
Deadlock and starvation: differences
• Process status:
– deadlock: processes are permanently blocked
because the resources never become available
– starvation: it is not certain the process will ever
acquire the requested resource
• Resource status
– deadlock: contended resources are not in use
– starvation: contended resources in continuous use
(by others)
 Causes of deadlocks
• Four necessary conditions for deadlock to occur are:
– Exclusive access: processes require exclusive access to a resource
– Hold and wait: processes hold on previously acquired resources
while waiting for additional resources
– No preemption: a resource cannot be preempted from a process
without aborting the process
– Circular wait: there is a set of blocked processes involved in a
circular wait
• The first three properties are generally desirable
– respectively to i) preserve resource integrity, ii) increase resource
utilization, iii) reduce waste of CPU time
 Deadlock handling policies
• Deadlock detection
– the system periodically (or when deadlock suspected) checks for
deadlocks, and a recovery procedure is started if one is detected
• Deadlock avoidance
– resources are granted only if the resulting system state is safe i.e.
there is at least one sequence of execution in which all processes
run to completion
• Deadlock prevention
– the system is designed so that granting requests never leads to a
deadlock
 Deadlock analysis
• Deadlock analysis is complicated by the number of
variants of the process-resource relationship
– how many and exactly which resources are needed?
– how many times a resource can be used?
– how many processes can simultaneously use a resource?
– ……
 Models of deadlock
• Depending on the type of resource request, a deadlock
can be classified according to one of four types
– Single-unit request model: vanilla variety
– AND request model: I need a CPU AND a disk AND a printer …
– OR request model: I need a disk OR a printer …
– AND-OR request model: I need a CPU AND (a disk OR a printer)
...
– P-out-of-Q request model: I need at least three consensus votes out
of five
 Types of resources
• Reusable resources
– examples: CPU, memory, I/O devices
– are not “consumed” by use
– fixed number of units
– when allocated to a process, they are held until the process is done
and then released
• Consumable resources
– examples: messages, interrupt signals, V operation in semaphores
– they vanish as a result of their use
– when allocated to a process, they are consumed and cease to exist
• Exclusive vs. shared access
– We will only consider exclusive access
 Theory vs Practice
• There is a whole theory for analyzing different
kinds of variants
– Refer to the textbook if you are interested in this
• Practice (if you are using pthread, Java, etc):
– Reusable: Acquire a lock first and finally release it
– Single-unit request: There is no atomic operation to
lock several units
– Exclusive
– We will cover this in this lecture
 Deadlock handling policies
• Deadlock detection
– the system periodically (or when deadlock suspected) checks for
deadlocks, and a recovery procedure is started if one is detected
• Deadlock avoidance
– resources are granted only if the resulting system state is safe i.e.
there is at least one sequence of execution in which all processes
run to completion
• Deadlock prevention
– the system is designed so that granting requests never leads to a
deadlock
 Deadlock detection
• Basic idea: check whether is cyclic waiting among
the blocked threads

• Implementation is subtle:
– Assume we can know whether a thread is waiting
and/or holding a lock
– Can we simply check each thread?
 Deadlock detection
• Checking thread one by one is not correct
– Thread 1 holds lock L1
– Thread 1 waits on L2
– Check L1 (Thread 1 holds L1 and waits for L2)
– Thread 1 gets L2 and finally releases both L2 and L1
– Thread 2 holds lock L2
– Thread 2 waits on L1
– Check L2 (Thread 2 holds L2 and waits for L1)
– False alarm: Deadlock between Thread 1 and 2
 Deadlock detection
• Checking threads one by one is not fully correct
• Checking must be done in an atomic way
– Option 1: Pause all threads (may be costly)
– Option 2: We will learn a solution later when
discussing distributed protocols

• On the other hand, for databases, since they can

abort and retry, false alarm may be acceptable
– Checking one by one may be an acceptable solution
 Deadlock handling policies
• Deadlock detection
– the system periodically (or when deadlock suspected) checks for
deadlocks, and a recovery procedure is started if one is detected
• Deadlock avoidance
– resources are granted only if the resulting system state is safe i.e.
there is at least one sequence of execution in which all processes
run to completion
• Deadlock prevention
– the system is designed so that granting requests never leads to a
deadlock
 Banker’s algorithm
• By Dijkstra

• Key idea:
– Each thread estimates the max number of each type of
resources it needs
– When a thread actually asks for a resource, check
whether granting the resource may create a deadlock in
the worst case.
 Banker’s algorithm
• What is the worst case?
– Each thread actually asks for the maximal number of
each type of resources

• How to check whether there is a deadlock?

– Check whether we can find one way to satisfy
everyone’s requirement.
 Banker’s algorithm
• Checking algorithm:
– 1. Check if any thread’s (maximal resource – acquired
resource) can be satisfied.
– 2. If yes, release all the thread’s acquired resource,
because this thread will not be blocked. Go to step 1.
– 3. If no, then deadlock.
– 4. If all threads can be released, then no deadlock
 Banker’s algorithm
• Checking algorithm:
– 1. Check if any thread’s (maximal resource – acquired
resource) can be satisfied.
– Which one to choose if multiple threads can be
satisfied?
– Theory: For reusable resource, the choice won’t affect
the conclusion. You can choose any of them to proceed.
 Banker’s algorithm
• Definitions for a system with n processors and m
resources:
Max - Availmatrix A = (a1 a2  am ) CurrentAvailmatrix D = (d1 d2  dm ) = A − Ck
n

k =1

 b11 b12  b1m   B1   e11 e12  e1m   E1 

       
b b  b2m   B2  e e  e2m   E2 
Max - Claimmatrix B =  21 22 = Current Need matrix E =  21 22 = B − C =
           
       
 bn1 bn2  bnm   Bn   en1 en2  enm   En 
 c11 c12  c1m   C1 
   
c c  c2m   C2 
CurrentAllocationmatrix C =  21 22
 
=
    ctor Fi = ( fi1
Request ve f i 2  fi m )
   
 cn1 cn2  cnm   Cn 
 Algorithm steps
• Step 1 - tentative accept of request
– D := D - F // update Current Avail matrix D
– Ci := Ci + Fi // update Current Alloc vector Ci
– Ei := Ei - Fi // update Current Need matrix Ei
• Step 2 - safe-state checking test
– see next slide in which
• freemoney = D
• loan[i] = Ci
• need[i] = Ei
• Step 3 - if test positive definitive accept of request,
otherwise roll back the updates of step 1
 Banker at work: safe-state checking
While (last_iteration_successful)
last_iteration_successful = false ;
for i = 1 to N do
if (finishdoubtful[i] AND need[i]  freemoney) then // need = claim - loan, how
// much process i still needs

finishdoubtful[i] = false ; // process can finish because

last_iteration_successful = true // need  free resources

free money = free money + loan[i] ; // process is able to finish thus

// it will repay the loan back

end if
end for
End while

if (free money == capital) then safe!

else not safe! ;
 Banker’s algorithm example (1)
• System with 3 processors and 3 resources, and
with the following matrices:
Max- AvailmatrixA= (2 4 3)
CurrentAvailmatrix D = (0 1 1) = A − Ck
n

1 2 2 k =1
 
Max- Claimm atrixB = 1 2 1
1 1 1  0 0 2
  
CurrentNeedm atrixE =  1 1 0 = B − C
1 2 0  0 1 0
   
m atrixC =  0
CurrentAllocation 1 1
1 0 1


• Request F1 = (0 0 1) should be granted?

 Banker’s algorithm example (2)
• Suppose the request is granted, the resulting state
would be the following:
 1 2 1
 
m atrixC =  0 1 1
CurrentAllocation
 1 0 1
 

CurrentAvailmatrix D = (0 1 0) = A − Ck
n

k =1

 0 0 1
 
CurrentNeedm atrixE =  1 1 0 = B − C
 0 1 0
 
 Banker’s algorithm example (3)
• The new state is safe
– P3 can complete (because E3  D) and thus can return
(1 0 1) to the pool of available resources
– D becomes (1 1 1); the outstanding needs of both P1
and P2 can be satisfied
 Limitation
• Estimating the max resource is not easy

• Computation overhead is high if many threads

• That’s why banker’s algorithm is not widely used

 Deadlock prevention
• Common guideline: order all locks and make sure
all threads grab locks in the same order
– Revisit dining philosopher: Following this rule, four
philosophers will pick left fork first and one will pick
right fork first (or the opposite way)

• Why?
– Order can break the cycle (cycle means no order)
 Reality
• In practice, OS (e.g. Linux) or PL (C, Java, etc)
does not provide any mechanism to
avoid/prevent/detect deadlock automatically.

• It is the developer’s responsibility to prevent

deadlocks in her program.
 Reality
• Developers often follow the deadlock prevention
guideline, but it is the developer’s responsibility
• If a deadlock is triggered, you can use tools like
pstack (for C) or jstack (for Java) to check why a
thread is blocked.
• Database systems have internal mechanisms to detect
deadlocks and roll back transactions, usually by just
using timeout