ICS 143 - Principles of Operating Systems: Lectures Set 5-Deadlocks Prof. Nalini Venkatasubramanian Nalini@ics - Uci.edu
ICS 143 - Principles of Operating Systems: Lectures Set 5-Deadlocks Prof. Nalini Venkatasubramanian Nalini@ics - Uci.edu
Operating Systems
■ System Model
■ Deadlock Characterization
■ Methods for handling deadlocks
■ Deadlock Prevention
■ Deadlock Avoidance
■ Deadlock Detection
■ Recovery from Deadlock
■ Combined Approach to Deadlock Handling
The Deadlock Problem
■ Resource
■ commodity required by a process to execute
■ Resources can be of several types
■ Serially Reusable Resources
❑ CPU cycles, memory space, I/O devices, files
❑ acquire -> use -> release
■ Consumable Resources
❑ Produced by a process, needed by a process - e.g.
Messages, buffers of information, interrupts
❑ create ->acquire ->use
❑ Resource ceases to exist after it has been used
System Model
■ Resource types
❑ R1, R2,….Rm
■ Each resource type Ri has Wi instances
■ Assume serially reusable resources
■ request -> use -> release
Conditions for Deadlock
❑ The following 4 conditions are necessary and sufficient for
deadlock (must hold simultaneously)
■ Mutual Exclusion:
❑ Only one process at a time can use the resource.
■ Hold and Wait:
❑ Processes hold resources already allocated to them while
waiting for other resources.
■ No preemption:
❑ Resources are released by processes holding them only after
that process has completed its task.
■ Circular wait:
❑ A circular chain of processes exists in which each process waits
for one or more resources held by the next process in the
chain.
Resource Allocation Graph
■ Process
■ Pi requests instance of Rj
■ Pi is holding an instance of Rj
Graph with no cycles
R1 R2
P1 P2 P3
R3 R4
Graph with cycles
R1 P2
P1 P3
R2 P4
Graph with cycles and deadlock
R1 R2
P1 P2 P3
R3 R4
Basic facts
❑ Prevention
❑ Design the system in such a way that deadlocks can never
occur
❑ Avoidance
❑ Impose less stringent conditions than for prevention, allowing
the possibility of deadlock but sidestepping it as it occurs.
❑ Detection
❑ Allow possibility of deadlock, determine if deadlock has
occurred and which processes and resources are involved.
❑ Recovery
❑ After detection, clear the problem, allow processes to complete
and resources to be reused. May involve destroying and
restarting processes.
Deadlock Prevention
❑ If any one of the conditions for deadlock (with
reusable resources) is denied, deadlock is
impossible.
❑ Restrain ways in which requests can be made
■ Mutual Exclusion
❑ non-issue for sharable resources
❑ cannot deny this for non-sharable resources (important)
■ Hold and Wait - guarantee that when a process requests
a resource, it does not hold other resources.
❑ Force each process to acquire all the required resources at
once. Process cannot proceed until all resources have
been acquired.
❑ Low resource utilization, starvation possible
Deadlock Prevention (cont.)
■ No Preemption
❑ If a process that is holding some resources requests
another resource that cannot be immediately allocated to it,
the process releases the resources currently being held.
❑ Preempted resources are added to the list of resources for
which the process is waiting.
❑ Process will be restarted only when it can regain its old
resources as well as the new ones that it is requesting.
■ Circular Wait
❑ Impose a total ordering of all resource types.
❑ Require that processes request resources in increasing
order of enumeration; if a resource of type N is held,
process can only request resources of types > N.
Deadlock Avoidance
Possible Deadlock!! 3
6
5 4
Banker’s Algorithm
■ Used for deadlock avoidance with multiple
instances of each resource type.
■ Each process must a priori claim maximum
use of each resource type.
■ When a process requests a resource it may
have to wait.
■ When a process gets all its resources it must
return them in a finite amount of time.
Data Structures for the Banker’s
Algorithm
■ Let n = number of processes and m =
number of resource types.
❑ Available: Vector of length m. If Available[j] = k, there are k
instances of resource type Rj available.
❑ Max: n × m matrix. If Max[i,j] = k, then process Pi may
request at most k instances of resource type Rj.
❑ Allocation: n × m matrix. If Allocation[i,j] = k, then process
Pi is currently allocated k instances of resource type Rj.
❑ Need: n × m matrix. If Need[i,j] = k, then process Pi may
need k more instances of resource type Rj to complete its
task.
■ 5 processes
❑ P0 - P4;
■ 3 resource types
❑ A(10 instances), B (5 instances), C (7 instances)
■ Snapshot at time T0
Example (cont.)
■ 5 processes
❑ P0 - P4;
■ 3 resource types
❑ A(10 instances), B (5 instances), C (7 instances)
■ Snapshot at time T0
Example (cont.)
■ Detection