resource management reusable disk blocks file descriptors semaphores consumable messages ...
TRANSCRIPT
Resource Management
ReusableDisk blocksFile descriptorsSemaphores
ConsumableMessagesPackets
Resource State
Available Total1 2+(1)+[1] 1 4Owns 2, request 1, remaining-claim 1
2 1Owns 1, cannot ask for any more
3 [2]Owns none, maximum claim is 2
Resource State Diagram Process 1 2 3Resource avail total
1 2+(1)+[1] 1 [2] 0 32 2 1+[1] 1+(1)+[1] 0 23 3 1+(1)[1] 1 0 2
3 RESOURCES 3 PROCESSESProcess 1 owns 2 units of R1, has requested
1 more with a remaining claim of 1 unit. There are no R1 units avail.
Deadlock Guarantees
No Effective Deadlock A request must be granted in finite time even if new requests are accepted.
No Deadlock A request must be granted in finite time assuming that no further requests are accepted.
Effective Deadlock Example
Process 1 2 3Resource avail total 1 1+[1] (2)+[2] 1+[1] 0 2
Process 1 and 3 alternate requests for 1 unit at a time. Process 2’s request for 2 units is never satisfied.
Necessary Conditions for Deadlock
(1) Processes claim exclusive control. (2) Processes hold resources while requesting
additional resources. (3) Resources cannot be forcibly removed
(preempted) from processes. (4) A circular chain of processes exist such that
each process holds one or more of the resources requested by its predecessor in the chain. If not, one of the processes would eventually receive a resource that it needed to complete.
Solution Classes
Prevention Static, works before programs execute
Avoidance Dynamic, check every request for safety Delay request if not safe
Detection/Recovery Check for “stuck” processes at intervals
Prevention
No exclusive control -- share everything No incremental requests
1. Collective requests2. Release all before requesting more
• Allow preemption• Havender’s Ordered Requests
• request a resource in class C(i) only if it holds no resources in any class C(j), j>=i.
• Dijkstra’s Minimal Progress
Havender Ordered Request Example(works for locks too!)
Class Resource Type 6 Printer
5 Disk 1
4 Tape Drives 1 and 2
3 Disk 2
2 Tape Drives 3 and 4
1 Memory
Avoidance - tasks required to provide maximum claim resource counts prior
to executionA request is granted only if it results in a
SAFE resource state.Requires Max Claim information.A safe execution sequence (SES) is an
execution schedule of processes (P1, P2, ... , Pn) such that for each P(i),
when it begins execution, its maximal claims can be satisfied by the available resources.
A Safe State
Process
1 2 3
Resource avail total
1 1+[4] 3+(1)+[4] 3+[3] 3 10
Safe Execution Sequences =(P3, P1, P2) (P3, P2, P1)
An Unsafe State
Process
1 2 3
Resource avail total
1 1+(1)+[4] 4+[3] 3+[3] 2 10
NO Safe Execution Sequence exists!
Banker’s Algorithm
On every request, search for a SES such that Every process can have its MAXIMUM CLAIM
satisfied in at least one execution order
Most Liberal because it gives away all resources if possible at the cost of execution order flexibility
Detection and RecoveryFor single-unit resources
(semaphores/files), a cycle is a necessary and sufficient condition for deadlock.
Detection and Recovery
Process
1 2 3 4
Resource available total
1 1+(1) 1 (1) 1 0 3
2 1+(1) 1 0 0 2
A cycle (P1 <-> P2) exists but no deadlock because P4 can terminate and give a resource back. Note: not single unit resources.
Recovery Options
Terminate operating systemTerminate all processes in a cycleTerminate one process in a cyclePreempt resources