V22.0202-001 Computer Systems Organization II (Honors) : Outline
V22.0202-001 Computer Systems Organization II (Honors) : Outline
V22.0202-001 Computer Systems Organization II (Honors) : Outline
Deadlocks (contd)
(Review) deadlock characterization methods for handling deadlocks deadlock prevention deadlock detection deadlock recovery combined approach to deadlock handling
Avoidance
deadlock can occur, but there are algorithms to avoid it relies on the OS having an advance model of possible resource requests from processes
No Preemption
processes cannot be forced to give up resources
Circular Wait
there is a sequence of processes p1, p2, ..., pn, p1 such that pi is waiting for a resource held by pi+1
3/20/2002
3/20/2002
Deadlock Prevention
Approach: Ensure that the necessary conditions for deadlocks are never satisfied Prevent one of the following from becoming true
Mutual Exclusion Hold and Wait No Preemption Circular Wait
3/20/2002
3/20/2002
Choice 2: A process releases any resources it is holding before it requests for new ones Choice 3: A process that is holding a resource immediately releases it if another of its requests cannot be satisfied currently
Choices
protocol 1: if a process is holding some resources and requests other resources that cannot be granted to it, all of its resources are taken away protocol 2: when a process requests additional resources, see if these resources are being held by a process that is itself waiting for new resources. In this situation, preempt the second process
Limitations
inefficient lowered resource utilization starvation
3/20/2002 7
3/20/2002
processes are required to sequence their resource requests in strictly increasing order of rank
i.e., they ask for all the smaller rank resources first P3
P1
1 3 2
P2
1 3 23
In our example
rank(memory) = 1, rank(disk) = 2, rank(printer) = 3
3/20/2002
3/20/2002
10
since a cycle of strictly increasing ranks cannot exist, there can exist no such cycle.
Limitations
inefficient
static allocation of resources reduces concurrency a process may need to be preempted even when there is no deadlock
restrictive
requires allocation of future resource requirements before it starts executing
Alternative approaches?
3/20/2002
11
3/20/2002
12
Deadlock Avoidance
Main idea:
request additional information about how resources are to be requested before allocating request, verify that system will not enter a deadlock state
resources currently allocated, future requests and releases ) if no: grant the request if yes: block the process
3/20/2002
R1
R2
<P3, P2, P1> is a safe sequence Say P1 requests R3: should this be granted?
This is a safe state, since a safe sequence <P2, P1, P3> exists P3 requests an additional unit. Should this request be granted? No, because this would put the system in an unsafe state
P1, P2, P3 will then hold 5, 2, and 3 resources (2 units are available) P2s future needs can be satisfied, but no way to satisfy P1s and P3s needs
P1
P2
P3
No, because an assignment edge from R3 to P1 would create a cycle in the RAG. [ No safe sequence exists ] Does this always imply a deadlock? No, because P1 can release R3 before requesting R1
16
R3
1. Work := Available; Finish[i] := false, for all i; 2. Find an i such that a. Finish[i] = false, and b. Needi Work if no such i, goto Step 4 3. Work := Work + Allocationi; Finish[i] := true; goto Step 2; 4. If Finish[i] = true for all i, then the system is in a safe state
resource availability Available[1..m] maximum demand Max[1..n, 1..m] current allocation Allocation[1..n, 1..m] potential need Need[1..n, 1..m]
P1 requests [0, 0, 1] Should this be granted? Allocate and check if system is in a safe state
Allocation = Available = Need = [[1, 2, 1], [0, 1, 1], [1, 0, 1]] [0, 1, 0] [[0, 0, 1], [1, 1, 0], [0, 1, 0]]
3/20/2002
P1
P2
P3
P1
P2
P3
R3
20
2. Find an i such that a. Finish[i] = false, and b. Requesti Work if no such i, goto Step 4 P3 3. Work := Work + Allocationi; Finish[i] := true; goto Step 2;
2. Find an i such that a. Finish[i] = false, and b. Needi Work if no such i, goto Step 4 3. Work := Work + Allocationi; Finish[i] := true; goto Step 2; 4. If Finish[i] = true for all i, then the system is in a safe state
P1
P2
P3
P1
P2
3/20/2002
21
3/20/2002
22
Deadlock Recovery
Only general principles known (read Section 8.7 for details) Two options Break the cyclic waiting by terminating some of the processes
choice 1: abort all deadlocked processes choice 2: abort one process at a time till deadlock resolved
No deadlock!
Enable at least one of the processes to make progress (by preempting resources from another)
issue 1: how is the victim process selected? issue 2: can the process handle resource preemption?
Deadlock!
3/20/2002
23
3/20/2002
24
Combined Approaches
Using only a single approach (prevention, avoidance, or detection + recovery) in isolation is not very effective Combination is superior General idea: Classify resources, use different approach for each Example: Consider a system with four classes of resources
3/20/2002
Next Lecture
Memory Management
logical versus physical address space swapping allocation paging, segmentation, and hybrids
internal resources (e.g., PCBs) main memory job resources (e.g., tape drives, files) swappable space process control blocks: user process memory: job resources: swappable space: use resource ordering (prevention) Why? use pre-emption (detection/recovery) require prior claims (avoidance) Why? preallocate; no hold & wait (prevention)
25
Reading
Silberschatz/Galvin/Gagne: Chapter 9
3/20/2002
26