Deadlock

1
Deadlock

• CS 537 - Introduction to Operating Systems

2
Defining Deadlock

• Deadlock is a situation where 2 or more processes
  are unable to proceed because they are waiting
  for shared resources.
• Three necessary conditions for deadlock
• able to hold more than one resource at a time
• unwilling to give up resources
• cycle
• Break any one of these three conditions and
  deadlock is avoided

3
Example

• Imagine 4 cars at an intersection

1
0
2
3
4
Example

• Lanes are resources.
• Deadlock has occurred because
• each car is holding 2 resources (lanes)
• none of the cars is willing to backup
• car 0 waits for car 1 which waits for car 2 which
  waits for car 3 which waits for car 0
• this is a cycle
• If any ONE of the above conditions can be broken,
  deadlock would be broken

5
System Resource-Allocation Graph

• Tool for detecting deadlock
• Shows which process is waiting for which resource
• called a request edge
• Shows which process is holding which resource
• called an assignment edge

6
System Resource-Allocation Graph

R0
R1
P0
P1
P2
R2
Request Edges
Assignment Edges
R0 --gt P0 R1 --gt P1 R2 --gt P0 R2 --gt P1
P1 --gt R0 P2 --gt R1
7
Dealing with Deadlock

• Three ways to deal with deadlock
• never allow it to occur
• allow it to occur, detect it, and break it
• ignore it
• this is the most common solution
• requires programmers to write programs that dont
  allow deadlock to occur

8
Not Allowing Deadlock to Occur

• Prevent processes from holding multiple resources
• not very realistic
• hard (or impossible) to get anything done if not
  allowed to hold more than one resource
• could provide multiple copies of resources
• not very economical
• some resources cant be duplicated (semaphore)

9
Not Allowing Deadlock to Occur

• Preempt Processes
• if process cant get a resource, give up what it
  has
• either all at once
• OR as other processes request what it has
• Who gets preempted?
• Can lead to severe starvation
• If resource is easily saved and restored, this is
  may be okay
• CPU, memory image

10
Not Allowing Deadlock to Occur

• Dont allow cycles to happen
• Force requests in specific order
• for example, must requests resources in ascending
  order
• Process A may have to wait for B, but B will
  never have to wait for A
• Must know in advance what resources are going to
  be used

11
Not Allowing Deadlock to Occur

• Force processes to declare needed resources
• process must do this before starting
• OS examines each processes requests and decides
  if a deadlock could occur
• dont allocate resource
• conservative approach
• Again, process must know what it wants before hand

12
Detecting Deadlock

• There are available resources
• availr of resources not allocated
• r is number of different resources in system
• There exists a set of requests for resources
• reqpr of units of resource r requested by
  process p
• There exists a set of resources allocated to a
  specific process
• allocpr of units of resource r currently
  held by process p

13
Detecting Deadlock

• 2 Systems - one deadlocked and one not

R0
R1
R0
R1
P0
P0
P1
P1
P2
P2
R2
R2
1) Deadlock Free System
2) Deadlocked System
14
Detecting Deadlock

• Basic idea
• examine the system for cycles
• find any job that can satisfy all of its requests
• assume it finishes and give its resources back to
  the system
• remove the processs node from the graph
• repeat the process until
• no nodes left - no deadlock
• cant remove any more nodes - deadlocked

15
Detecting Deadlock

• Algorithm
• boolean deadlock(int req)
• boolean done new booleanN // N of
  processes
• initialize done to all false
• for(int p0 pltN p)
• find p such that (!donep reqp lt
  avail)
• if (p is not found)
• return true // DEADLOCK
• else
• avail allocp
• donep true
• return false // NO deadlock

16
Example of Algorithm

• Examine the following system

r 3 N 5 availr 0, 0, 1 reqnr
(0, 0, 1), (1, 0, 0), (0, 0, 0) allocnr
(2, 0, 0), (0, 0, 2), (1, 1, 3) Now trace
through algorithm. Final solution No deadlock.
R0
R1
P0
P1
P2
R2
17
Bankers Algorithm

• This is a method for detecting if allocating a
  could lead to deadlock
• Dont allow allocation if deadlock could occur
• conservative approach
• requires processes declare up front what they
  need
• this is a processes credit

18
Bankers Algorithm

• boolean bankers (int p, int breq)
• // do some error checking - make sure not
  exceeding credit, etc.
• avail - breq
• creditp - breq
• allocp breq
• if( safe() )
• return true
• else
• restore avail, credit, and alloc to original
  values
• return false
• boolean safe()
• return !deadlock(credit)

19
Bankers Algorithm

• Consider the following set of credits,
  allocations, and availabilities

units of resources initial availr 8, 7, 7

availr 4, 2, 3
current credits for each process
20
Bankers Algorithm

• Consider the following requests
• P3 requests (2, 2, 2)
• overdrawn - denied
• P5 requests (5, 0, 0)
• only 4 available - must wait
• P3 requests (3, 1, 0)
• run algorithm (assume adjusted credits become
  requests for deadlock detection)
• notice this is conservative
• in this case, request can be granted

21
Deadlock Recover

• first, must be able to detect deadlock
• use deadlock method described earlier
• running time is O(n2 m)
• this can lead to poor performance if done on
  every request - processes requests resources
  frequently
• run deadlock algorithm at set intervals
• how often is deadlock likely to occur?
• how many processes will be affected?

22
Deadlock Recovery

• So what to do if deadlock is discovered?
• OS can start killing processes
• OS can revoke resources from processes
• Both of the above solutions will eventually end a
  deadlock
• which processes to kill?
• which resources to revoke?

23
Process Termination

• Two solutions
• kill all deadlocked processes
• very costly (work is lost)
• kill one process at a time until deadlock is
  broken
• high overhead (must re-run deadlock algorithm
  after each killing)
• still have cost of lost work
• which process to kill?

24
Process Termination

• Which process to kill?
• must have some type of cost analysis
• kill lowest priority process
• kill youngest process (least amount of work done)
• kill process with most resources (gives greatest
  chance of ending deadlock)
• kill process with most outstanding resource
  requests (removes the most request edges from
  graph)
• Will have to restart killed processes later
• avoid starvation

25
Resource Preemption

• Let processes stay alive but revoke some of their
  resources
• Again, must select process to preempt
• take resources from biggest hog
• take resources from youngest

26
Resource Preemption

• What to do with preempted process?
• rollback to safe state
• difficult to determine what was safe state
• must keep extra state around
• example semaphore
• if preempt the semaphore from some process, it
  must be rolled back to way it was before entering
  critical section
• otherwise there is an inconsistant state
• Beware of starvation

27
Dining Philosophers

• Philosophers sitting around a dining table
• Philosophers only eat and think
• Need two forks to eat
• Exactly as many forks as philosophers
• Before eating, a philosopher must pick up the
  fork to his right and left
• When done eating, each philosopher sets down both
  forks and goes back to thinking

28
Dining Philosophers
29
Dining Philosophers

• Only one philosopher can hold a fork at a time
• One major problem
• what if all philosophers decide to eat at once?
• if they all pick up the right fork first, none of
  them can get the second fork to eat
• deadlock

30
Philosopher Deadlock Solutions

• Make every even numbered philosopher pick up the
  right fork first and every odd numbered
  philosopher pick up the left fork first
• Dont let them all eat at once
• a philosopher has to enter a monitor to eat
• can only get into the monitor if no one else in
  it
• only one philosopher is allowed to eat at a time

31
Philosopher Deadlock Solution
monitor diningPhilosopher int state new
int5 static final int THINKING 0 static
final int HUNGRY 1 static final int EATING
2 condition self new condition5 public
diningPhilosphers for(int i0 ilt5 i)
statei THINKING public pickup(int i)
statei HUNGRY test(i) if (statei
! EATING) selfi.wait public putDown(int
i) statei THINKING test((i5)
6) test((i1) 6) private test(int i)
if( (state(i 5) 6 ! EATING)
(statei HUNGRY) (state(i 1)
6 ! EATING) ) statei
EATING selfi.signal