



Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
deadlock in operating syatem
Typology: Study notes
1 / 7
This page cannot be seen from the preview
Don't miss anything!
Mount Holyoke College Spring 2008
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:
The traffic analogy can become more complex with two-way intersections – gridlock!
We have seen the potential for deadlock when using semaphores:
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.
Four conditions must hold simultaneously for deadlock to arise:
If any one of these conditions does not hold, deadlock cannot occur.
We model systems for our study of deadlock using directed graphs.
The vertices of our graph are processes , represented by circles,
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.
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.
Here, we make sure there is no deadlock by guaranteeing that one of the four necessary conditions cannot occur.
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:
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)
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.
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.