Deadlock

1
Deadlock
2
Stepping on each others feet - I

• Thread T1
• b1 allocate()
• b2 allocate()
• release(b1)
• release(b2)

• Thread T2
• b1 allocate()
• b2 allocate()
• release(b1)
• release(b2)

A serial execution is ok, but interdigitation can
cause deadlock!
3
Stepping on each others feet - IIThe TENEX case

• If a process requests all systems buffers,
  operator console tries to print an error message
• To do so
• lock the console
• request a buffer
• DUH!

4
Stepping on each others feet - III

• Thread T1
• open(f1, write)
• open(f2, write)
• close(f1,f2)

• Thread T2
• open(f2, write)
• open(f1, write)
• close(f1,f2)

A serial execution is ok, but interdigitation can
cause deadlock!
5
Issues

• How can we tell if a system is deadlocked?
• How can a deadlocked system recover?
• How can deadlocks be prevented in the first place?

6
Model

• A set of resources
• e.g. files, buffers, semaphores?
• System is defined by
• a set of states ?
• each state represents the allocation status of
  the resources
• a set of processes ?
• each process pi can request, acquire, release
  resources
• each pi can be described by the set of state
  transitions it can generate (pi is a partial
  function from ? to 2? )

7
Transitions

• If pi can change the state of the system from ?1
  to ?2 we write ?1 ?i ?2
• We write ?a ? ?b if ?b can be reached from ?a ,
  i.e. if either
• ?a ?b
• ? pi ?a ?i ?b
• ? ?c , pi ?a ?i ?c and ?c ? ?b

8
Key Definitions

• Blocked pi is blocked in ?a if ?? ?b ?a ?i ?b
  
• Deadlocked pi is deadlocked in ?a if ??b ?a
  ? ?b ,
• pi is blocked in ?b
• Deadlock state ?a is a deadlock state if ? pi
  pi is deadlocked in ?a
• Safe state ?a is a safe state if ? ?b ?a ?
  ?b ?b is not a deadlock state

9
Example I
1
1
1
2
?1
?2
?3
?4
?5
2
2

• ? ?1, ?2, ?3, ?4, ?5 ? p1, p2
• p1 (?2, ?3) , (?4, ?5) , (?3, ?4)
• p2 (?2, ?1) , (?3, ?2) , (?5, ?4)

• ?1 p1 deadlocked, p2 deadlocked deadlock state
• ?2 not safe (?1 deadlocked), not deadlock
• ?3 not safe, not deadlock
• ?4 p2 blocked, safe state
• ?5 p2 blocked, safe state

10
Example 2

• File allocation example from before

1
,
1 ,
1 , 1
, 2
1 , 2
2
No safe states One deadlock state
2 , 2
11
Necessary Conditions for Deadlock

• Mutual exclusion
• Hold and Wait
• No preemption
• Circular waiting

12
How to deal with deadlock

• Two basic approaches
• detect deadlock and abort (breaks no-preemption)
• prevent deadlock (breaks one of the other
  conditions)

13
Reusable Resource Graphs

• Direct bipartite graphs
• process nodes are circles
• resource nodes are squares
• single resources as circles within the
  corresponding resource node square
• tj total number of resources at resource node
  rj
• (a,b) number of edges from a to b
• Two requirements
• ?i (rj , pi) tj (cant allocate more
  than available)
• ? i,j (pi , rj) (rj , pi) tj (no
  stupid deadlocks)

14
Examples
r
p1
p2

• Requesting buffers

r1
Allocating files
p2
p1
r2
15
Evolving the Resource Graph

• A resource graph changes as the state of the
  system changes
• pi requests rj
• pi must have no outstanding requests
• pi may request multiple units (say ui)
• add ui edges from pi to rj
• acquisition
• pi must have outstanding requests on rj, and all
  such requests must be satisfiable
• reverse the direction of all edges
• release
• pi must have no outstanding requests
• pi may release any nonempty set of resources
• erase the appropriate subset of edges from rj to
  pi

16
Example
r
p1
p1
p1
Release
Acquisition
Request
17
Deadlock Detection

• Deadlock implies that there is no sequence of
  state transitions that would allow processes to
  make progress
• Then, as long as there exists one sequence of
  actions through which some process can make
  progress, there is no deadlock
• IDEA
• Simulate the most favorable execution of each
  unblocked process. If that execution exibits
  deadlock, all will
• Simulate by reducing resource graph

18
Reducing the resource graph

• A process pi is blocked if
• (pi , rj) ?k (rj , pk) gt tj for all rj
• Reduction Step
• Find unblocked pi which is not isolated
• Erase all edges incident on pi this is
  equivalent to acquiring and releasing all pis
  resources
• When there is no such pi, the graph is
  irreducible
• An irreducible graph that contains no edges is
  completely reducible

19
Example
Reduce by p1
p2 is blocked
Reduce by p2
We obtained a fully reducible graph!
20
Deadlock Theorem

• Theorem
• A resource graph represents a deadlock state if
  and only if it is not completely reducible.
• Is this really useful?

Yes, because, fortunately, the order in which
reductions are performed does not affect the
final outcome of the reduction process!
21
Observations 1

• If deadlock, then cycle in resource graph
• but the opposite is not true!

The resource node had some of its resources non
allocated what if all resources had been
allocated?
22
Observations 2

• A graph is expedient if all of its resources have
  been allocated.
• Is a cycle in an expedient graph a sufficient
  condition for deadlock?

23
Knots

• A knot is a set of nodes that are mutually
  reachable from each other, and no other node is
  reachable from them.

a
a
b
b
e
c
e
c
d
d
24
Observations 3

• If expedient knot, then deadlock
• but not necessary!

r2
p3
p1
Expedient, no knot, but deadlock!
p2
r1
25
Observations 4

• If resources are single unit, (?j tj 1) then
  deadlock iff cycle

26
OK, we detected the deadlockthen, what?

• Select a victim and either
• terminate the victim
• costly
• how is the victim selected?
• preempt its resources
• rollback
• starvation

27
Deadlock Prevention - 1

• Must make sure that at least one of the 4
  necessary conditions does not hold
• ? Mutual Exclusion
• difficult to avoid no collaboration!
• sometime possible (read-only files)
• ? Hold and Wait
• Force each process to allocate all resources at
  the beginning
• Allow a process to request resources only if it
  has none
• low resource utilization
• possible starvation for processes asking popular
  resources

28
Deadlock Prevention - 2

• ? No preemption
• preempt all resources held while waiting on a
  resource
• when requesting for a resource
• if it is available, allocate it
• if it is not available, but it is held by another
  process that is waiting, preempt the resource
• ? Circular wait
• impose a total order on all resource types
• require each process to request resources in
  strictly increasing order

29
Deadlock Avoidance

• Determine whether, by allowing allocation, we
  could get a deadlock, i.e. check if by allowing
  allocation the system could enter a state that is
  not safe
• Simple way to do it
• have each process declare the maximum number of
  resources of each type that it may need

30
Claims Graph

• Claim graph Resource graphs that also contains
  edges that represent potential requests (each
  process needs to specify max claim to each
  resource)

p1
p1
p1
Not completely reducible (no deadlock though
(yet))
Still completely reducible
r
p1
p2
p2
p2
p2
Requests one unit
Requests one unit
31
Bankers Algorithm (Dijkstra Habermann)

• if request gt needa,i error
• if request gt availablei wait
• availablei availablei - request
• alloca,i alloca,i request
• needa,i needa,i - request
• if (not safe()) undo request and wait
• safe()
• worki availablei
• while (? u not finishu and
• (need(u,i) worki))
• worki workiallocu
• finishu true
• safe ?u finishu

• Variables
• availablei units of ri not allocated
• ca,i max claim of pa on ri
• alloca,i number of units of ri allocated to pa
• needa,i number of potential requests ca,i -
  alloca,i
• finishi one entry per process, true if process
  can finish
• worki one entry per process
• -----------
• Let pa attempt to allocate request units of ri