Download Deadlock in operating systems and more Study notes Operating Systems in PDF only on Docsity!
Computer Science 322
Operating Systems
Mount Holyoke College Spring 2008
Topic Notes: Deadlock
The idea of deadlock has come up a few times so far:
A group of processes is deadlocked if each process is waiting for an event that can be caused only by one of the other waiting processes.
Consider a one-lane tunnel (see http://www.teresco.org/pics/xc-19990722-0810/ disk09/mvc-018f.jpg) or underpass:
- One-lane traffic inside the tunnel
- The lane in the tunnel is a shared resource
- If a deadlock like this one occurs, we must tell one of the cars it has to give up its right to the resource and rollback
- This may mean more than one car has to back up
- Starvation is possible if we keep allowing cars from one direction to enter
The traffic analogy can become more complex with two-way intersections – gridlock!
We have seen the potential for deadlock when using semaphores:
P 0 P 1
wait(Q); wait(R); wait(R); wait(Q); ... ... signal(R); signal(Q); signal(Q); signal(R); ... ...
This is a situation that came up with the original “solution” to the dining philosophers.
We will consider processes that need access to more general resources. These could be any non- preemptable resources, such as tape drives or CD burners, in addition to things like the semaphores.
Requirements for Deadlock
Four conditions must hold simultaneously for deadlock to arise:
- Mutual exclusion : only one process at a time can use a resource
- Hold and wait : a process is holding, but not necessarily using, at least one resource and is waiting to acquire additional resources held by other processes
- No preemption : a resource can be released only voluntarily by the process holding it, after that process has completed its task
- Circular wait : there exists a circular chain of waiting processes, each of which it waiting for a resource held by the next process in the chain
Pn P
P
P
If any one of these conditions does not hold, deadlock cannot occur.
Resource Allocation Graphs
We model systems for our study of deadlock using directed graphs.
The vertices of our graph are processes , represented by circles,
P
and resources , represented by squares, which may have a number of “dots” inside to indicate multiple equivalent instances of a resource.
Deadlock! P 3 cannot continue until it acquires an R 2. But we know that P 2 can’t continue until it gets an R 3 , which isn’t going to happen until P 3 can go. But P 1 is waiting for an R 1 , which isn’t available until P 2 can go... We have a problem. No process can continue.
However, a cycle alone is not enough to guarantee deadlock:
Here, there is a cycle, but P 2 and P 4 are not waiting for anything. That means that eventually they will free their resources, and the other processes can get what they need.
If there is a single instance of each resource, a cycle in the resource allocation graph means we have deadlock. When there are multiple instances, it only means there is a possibility of deadlock.
Dealing With Deadlocks
Most common approach: ignore the problem! It probably doesn’t happen that much and it’s hard to deal with, so forget about it and if it happens we’ll just chalk it up to an OS bug or something. End of story.
But that’s not good enough for us. We’re going to look at three ways to deal with deadlock: prevention , avoidance , and detection and recovery.
Deadlock Prevention
Here, we make sure there is no deadlock by guaranteeing that one of the four necessary conditions cannot occur.
- Mutual Exclusion : This is a tough one to break, since a non-shareable resource is a non- shareable resource. But if nothing else, we should make sure that the resource really does require that concurrent access be restricted. But really, there’s no help here.
- Hold and Wait : To break this, we’d have to require that a process that needs multiple re- sources requests them as a group. This may or may not be possible, and even if it is, it might cause a process that needs resource A for a long time, but resource B for a short time (con- currently), to hold on to B when it otherwise might be available for use by other processes. This can lead to low resource utilization and potentially to starvation.
- No Preemption : We could require that a process that fails to acquire a requested resource immediately gives back any other resource it already has. This is great, except in those cases where the resource really isn’t preemptable. Taking away a CD burner when the CD is half written isn’t a very good solution.
- Circular Wait : One possibility is to rank all resources, and only allow processes to request concurrent resources from low rank to high rank order. If you think about this a bit, you can convince yourself that this ensures that no cycles can form in the resource allocation graph. This may be difficult to implement, however, as an appropriate ranking may not be readily apparent.
Deadlock Avoidance
If we have some additional information available, we can use it to avoid deadlock.
For example, we could require that each process declare a priori the maximum number of each resource that it will ever need.
These values, along with the current number of resources allocated to each process and the number of resources available, form a resource allocation state.
We want to ensure that the system stays in a safe state. A safe state is one in which, given the current allocations, there is guaranteed to be an ordering of the processes that will allow all pro- cesses to get the resources they need and (eventually) run to completion. The first process to run must be able to satisfy its resource needs with what it is allocated plus what is available. The next
For single-instance resources, we need only ensure that we do not grant any request that would introduce a cycle in the augmented resource graph.
For multiple instances of resources, we need something a little more complicated:
Banker’s Algorithm (Dijkstra)
The decision to grant a resource or make a process wait even if the resource is available is made by checking if the state would become unsafe.
We use an example to see the Banker’s Algorithm in action. (See class handout: bankers.pdf)
Deadlock Detection and Recovery
Since the Banker’s Algorithm might be too expensive to run every time a resource is requested (in fact, at least one author, Tanenbaum, points out that no one uses it), we might just let processes get resources, then “once in a while” check for deadlock by running the “safety algorithm” or by checking for cycles in the resource allocation graph.
If we take this approach and discover that there is a deadlock, how to deal with it?
We could try to preempt a resource, though, that might force the process that had the resource to have to “undo” some of its computation and repeat it when it gets the resource back. This is complicated and can be costly (have you ever tried to “unwrite” a partially written CD?).
Since that option is so complex, we might just terminate processes to free their resources and have them restart. How do we choose a victim process? We could kill all deadlocked processes, but probably just one at a time until we can break the deadlock. Ideally we try to minimize the cost – avoid terminating a process that is almost done, or one that doesn’t have enough resources to make much of a difference, or the boss’ process.
Final Words on Deadlock
The statements that most systems do not worry about deadlock is a bit misleading. While no systems manage resources with something as elaborate as the Banker’s Algorithm, many systems work to avoid deadlock in specific cases, such as with the allocation of file descriptors, process table entries, and memory.
While kernel deadlocks are infrequent in real systems, user process deadlocks are certainly com- mon, which is why we study the 4 conditions.
