Lecture 013

Deadlock Avoidance

Assumptions:

• Predeclear Resources:

  • In detail: declare resource request and release patterns, and multiple alternative resource need
  • Easier: declare maximum resources need

• Proceed to Completion:

  • Process don't hold resources for ever
  • Process complete in reasonable time (ie. we can block other process in favor of current process)

Safe Execution Sequence:

• Definition: $P_1 \to P_2 \to ... \to P_n$ is safe if $P_i$ can be satisfied by current free resources $F$ and resources held by $P_1, P_2, ..., P_{i-1}$ for all $i$.

• Properties: $P_i$'s waiting is bounded. No deadlock.

Safe State:

• Definition: at least one safe execution sequence exists in the system.

• Worst Case: all processes need all resources (serial execution). In this case safe execution sequence still exist

Resource Manager:

• Naive Resource Manager: grant request if available, otherwise block. This can lead to deadlock when processes hold resources while it needs more.

For above image, $P_1$, $P_0$, or $P_2$ might not ask for "Room" resources, but we need to prepare for the worst case.

Implementation:

• Cycle Detection: pretend we grant an request, we check if dependency graph has cycle. If yes, wait. (Graph is computational expensive)

• Banker's Algorithm: pretend allocate resources greedily so long as one process can finish. Continue for all process. If all processes can finish, grant request. Otherwise, wait. (Greedy algorithm works since system's resource linearly increases when process finish.)

Avoidance

• more flexible than prevention

• rejecting all unsafe states can be inefficient (since system can enter unsafe state and return safely in some chance)

• process must pre-declare max resource need

• system throughput is reduced compared to "detection and recovery" approach

Deadlock Recovery

Detection:

• method 1: occasionally lock entire system, and scan graph $O(n^2)$ and see if cycle exists. If yes, we have deadlock.

• method 2: banker's algorithm for detection

• how often: can't scan too often or too rarely (clock time interval? CPU idle?)

Recovery:

• method 1: kill all processes.

  • but everybody need to start over, never complete

• method 2: kill one process

  • but which one? a cycle might not be fully resolved by killing one. also long running-process can never complete

• method 3: send EDEADLOCK to process, wanting them to voluntarily release resources ("please release before you retry")

  • but who to send? if "lowest number", then we might have starvation.