Deadlock - PowerPoint PPT Presentation

About This Presentation
Title:

Deadlock

Description:

Title: Deadlock Author: Lorenzo Alvisi Last modified by: Lorenzo Alvisi Created Date: 10/5/2000 4:05:58 AM Document presentation format: On-screen Show – PowerPoint PPT presentation

Number of Views:185
Avg rating:3.0/5.0
Slides: 32
Provided by: Loren93
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com