Operating sytems manages many shared resources (e.g., file, memory, CPUs, status tables, disk drives, messages). Often have many processes competing for limited resources.
Model of process action:
request( resource ) use( resource, time ) release( resource )This environment can lead to deadlock when processes need several resources.
Necessary conditions for deadlock (Coffman Conditions):
Consider the following resource graph:
R1 R2 R4 +----+ +----+ +-------+ 4 resouces | 0 | | 0 | | 0 0 0 | 3 processes +----+ +----+ +-------+ ^ \ ^ \ P1 "holds" an R3 (of which / v / v there are 2). It is waiting for P1 P2 P3 an R1 (now held by P2). P2 has ^ ^ an R1 and an R3; it is waiting \ / for an R2. +-----+ | 0 0 | Note: a "request" edge goes from a process to a resource, +-----+ an "allocation" edge goes from a resource to a process. R3Has deadlock occurred? No, since this graph has no cycles.
R1 R2 R4 +----+ +----+ +-------+ | 0 | | 0 | | 0 0 0 | +----+ +----+ +-------+ ^ \ ^ \ / v / v P1 P2 P3 ^ ^ / \ / / \ / v +-----+ | 0 0 | +-----+ R3Now there is a cycle. P3 is waiting on something held by P1. P1 is waiting on something held by P2 and P2 is waiting on something held by P3.
If cycles exist, may or may not be deadlock. If some process in cycle is waiting on a resource held by a process which is not blocked, that process may complete and cycle will be broken (direction of arrow will change).
Ostrich Algorithm (Do Nothing)
Deadlocks are allowed to occur, detected through model checking (FSM), and fixed.
Prevention depends on ensuring at least one of the four necessary conditions cannot occur:
|mutual exclusion||not feasible for many resources.|
OK for disks, usually not for files.
|hold & wait||can preallocate everyting which a process MIGHT require.|
advantage: easy (mostly)
disadvaantage: expensive. Will tie up possibly scarce resources for long periods of time, idle.
Can also require require process to release everything anytime it requests something new. Not always feasible.
|no preemption||if a process requests and is blocked, then resources it holds are preempted when required by another process.
Works for processes whose state is easily saved and restored. Does not work well for files.
|circular wait||impose total ordering on resource types, then require processes to only request resources in ascending order.|
disadvantage: useful ordering often not feasible.
Note: If OS uses deadlock prevention (as opposed to avoidance, discussed next) not additional runtime overhead, though process may be needlessly delayed.
Use additinal info about active processes to decide, for example, an ordered list of resource use for each process.
Example: proc 1 will use file 1 then file 2 then release both proc 2 will use file 2 then file 1 then rel. bothThen OS considers each reqest and blocks or allocates based on keeping system in a SAFE state. I.e., given each process useage, a FEASIBLE SEQUENCE exists: some process can complete no matter what, release its resources, which will allow at least one more process to complete no matter what, and so on until all processes have completed).
Based on knowing the max number of each resource which a process may require.
Algorithm is simple: before granting any new resource request, make sure:
Alloc Max Avail ABCD ABCD ABCD p0 0012 0012 1520 p1 1000 1750 p2 1354 2356 p3 0632 0654 p4 0014 0656Can all process complete given current resources, max, alloc and avail? I.e. does a feasible sequence exist?
p0 can complete (since Max - Alloc >= Avail), Avail becomes 1532, then p2 can complete, then p3 then p4. No matter what!
Problem with banker's alg. O(mn2) (m resources, n processes). This leads to consideration of deadlock detection algorithms.
Once deadlock is detected, what next:
Is starvation possible? if you always use the same algorithm to select a victim, will you always tend to select the same victim?
Copyright ©1998, G. Hill Price
Send comments to G. Hill Price