Deadlock
- 4 conditions must hold (necessary) for deadlock to occur:
- mutual exclusion:
- resource is not shared; process has exclusive control
- hold and wait:
- process may hold one resource and request another
- circular waiting:
- p1 may hold R1 and request R2
- p2 may hold R2 and request R1
- (can extend to > 2 processes)
- no preemption:
- only the process holding a resource can release it
- process does not withdraw resource request if
if it is unavailable
- gridlock example
Dealing with Deadlock
- prevention
- detection/recovery
- avoidance
Introduce state transition diagram
request Rs allocate Rs release Rs
Si -------------> Sj -------------> Sk -------------> Sl
<------------- |
withdraw | request Rt
v
Sm
- sequence of requests, allocations, deallocations, etc.
Prevention
- conservative scheme: undercommits resources
- mutual exclusion
- nothing can be done about that!
- break hold and wait
a) process must request all resources at once
- hard to know all future resource needs
- not plausible for interactive systems
b) process must release all resources before
requesting new ones
- huge overhead: closing files, re-opening, etc.
- may lead to starvation
- break cycle
a) don't allow cycles in process-resource graph
- e.g. the reverse direction dining philosopher
b) total order:
- establish total order on all resources
(consumable and renewable)
- process can only request resource Rj if
for all Rk held process, j > k
- otherwise, must first release all Rk
where k > j, then reaquire
- allow preemption
- if requested resource not available immediately,
process withdraws request and does something else
- assumes that process always has "something else" to do
- can lead to livelock: processes running, but not
doing anything useful
Detection
- liberal: grant resources wherever possible
- check periodically for deadlock
- if detected, then can:
- abort all D-lock processes
- rollback D-lock processes (must be able to reverse actions)
- abort D-lock processes one by one until deadlock broken
- preempt resources one by one until deadlock broken (rollback)
Avoidance
- conservative scheme, undercommits
- only grant resource after verifying that there is some
sequence of state transitions by which all processes can
execute
- before first request, process must declare maximum claim
- safe state: if every process were to excercise its maximum
claim, there is some sequence by which these requests could
be granted that would not lead to deadlock
- how to determine this? Banker's Algorithm