UNIT 4 -DEADLOCKS

• A resource can be a hardware device (e.g., a Blu-ray drive) or a piece of information (e.g., a record in a database).

• Preemptable and Nonpreemptable Resources

• A preemptable resource is one that can be taken away from the process owning it with no ill effects. Memory is an
example of a preemptable resource.

• A nonpreemptable resource, in contrast, is one that cannot be taken away from its current owner without potentially
causing failure.

• Deadlock can be defined formally as follows: A set of processes is deadlocked if each

process in the set is waiting for an event that only another process in the set can cause.
 Conditions for Resource Deadlocks

• Coffman et al. (1971) showed that four conditions must hold for there to be a (resource)
deadlock:
• 1. Mutual exclusion condition. Each resource is either currently assigned to exactly one
process or is available.
• 2. Hold-and-wait condition. Processes currently holding resources that were granted earlier
can request new resources.
• 3. No-preemption condition. Resources previously granted cannot be forcibly taken away
from a process. They must be explicitly released by the process holding them.
• 4. Circular wait condition. There must be a circular list of two or more processes, each of
which is waiting for a resource held by the next member of the chain.
 Deadlock modelling
• The graphs have two kinds of nodes: processes, shown as circles, and resources, shown as squares.

• A directed arc from a resource node (square) to a process node (circle) means that the resource has
previously been requested by, granted to, and is currently held by that process.

• In Fig. 6-3(a), resource R is currently assigned to process A. A directed arc from a process to a resource means
that the process is currently blocked waiting for that resource.

• In Fig. 6-3(b), process B is waiting for resource S.

• In Fig. 6-3(c) we see a deadlock: process C is waiting for resource T, which is currently held by process D.
Process D is not about to release resource T because it is waiting for resource U, held by C. Both processes will
wait forever. A cycle in the graph means that there is a deadlock involving the processes and resources in
the cycle (assuming that there is one resource of each kind). In this example, the cycle is C − T − D − U − C.
 THE OSTRICH ALGORITHM
• Mathematicians find it unacceptable and say that deadlocks must be prevented at all costs.
• Engineers ask how often the problem is expected, how often the system crashes for other reasons, and
how serious a deadlock is.
• If deadlocks occur on the average once every five years, but system crashes due to hardware failures
and operating system bugs occur once a week, most engineers would not be willing to pay a large
penalty in performance or convenience to eliminate deadlocks.
• To make this contrast more specific, consider an operating system that blocks the caller when an open
system call on a physical device such as a Blu-ray driver or a printer cannot be carried out because the
device is busy.

• Typically it is up to the device driver to decide what action to take under such circumstances.
Blocking or returning an error code are two obvious possibilities. If one process successfully opens
the Blu-ray drive and another successfully opens the printer and then each process tries to open the
other one and blocks trying, we have a deadlock. Few current systems will detect this.
Deadlock Detection with One Resource of Each Type

• consider a system with seven processes, A though G, and six resources, R through W.
• The state of which resources are currently owned and which ones are currently being
requested is as follows:
• 1. Process A holds R and wants S.
• 2. Process B holds nothing but wants T.
• 3. Process C holds nothing but wants S.
• 4. Process D holds U and wants S and T.
• 5. Process E holds T and wants V.
• 6. Process F holds W and wants S.
• 7. Process G holds V and wants U.
The question is: ‘‘Is this system deadlocked,
and if so, which processes are involved?’’
To answer this question, we can construct the
resource graph of Fig. 6-5(a).
This graph contains one cycle, which can be
seen by visual inspection. The cycle is shown in
Fig. 6-5(b).
From this cycle, we can see that processes D, E,
and G are all deadlocked.
Processes A, C, and F are not deadlocked
because S can be allocated to any one of them,
which then finishes and returns it. Then the
other two can take it in turn and also complete.
 Deadlock Detection with Multiple Resources of Each Type.
• When multiple copies of some of the resources exist, matrix-based algorithm for
detecting deadlock among n processes, P1 through Pn.
• Let the number of resource classes be m, with E1 resources of class 1, E2 resources
of class 2, and generally, Ei resources of class i (1 ≤ i ≤ m). E is the existing
resource vector. It gives the total number of instances of each resource in existence.

• For example, if class 1 is tape drives, then E1 = 2 means the system has two
tape drives. At any instant, some of the resources are assigned and are not
available.

• Let A be the available resource vector, with Ai giving the number of instances of
resource i that are currently available (i.e., unassigned).
• If both of our two tape drives are assigned, A1 will be 0.
• Now we need two arrays, C, the current allocation matrix, and R, the request matrix.
• The ith row of C tells how many instances of each resource class Pi currently holds.
Thus, Cij is the number of instances of resource j that are held by process i.
• Similarly, Rij is the number of instances of resource j that Pi wants.
• Here we have three processes and four resource classes, which we have arbitrarily labeled tape drives, plotters,
scanners, and Blu-ray drives. Process 1 has one scanner. Process 2 has two tape drives and a Blu-ray drive. Process 3
has a plotter and two scanners. Each process needs additional resources, as shown by the R matrix.

The first one cannot be satisfied because there is no Blu-ray drive available. The
second cannot be satisfied either, because there is no scanner free. Fortunately, the
third one can be satisfied, so process 3 runs and eventually returns all its
resources, giving A = (2 2 2 0)

At this point process 2 can run and return its resources, giving A = (4 2 2 1) Now
the remaining process can run. There is no deadlock in the system .
Recovery from Deadlock

• Recovery through Preemption

• In some cases it may be possible to temporarily take a resource away from its current owner
and give it to another process.

• For example, to take a laser printer away from its owner, the operator can collect all the sheets
already printed and put them in a pile. Then the process can be suspended (marked as not
runnable). At this point the printer can be assigned to another process. When that process finishes,
the pile of printed sheets can be put back in the printer’s output tray and the original process
restarted.

• The ability to take a resource away from a process, have another process use it, and then give it
back without the process noticing it is highly dependent on the nature of the resource.

• Choosing the process to suspend depends largely on which ones have resources that can
easily be taken back.
Recovery through Rollback
• Checkpointing a process means that its state is written to a file so that it can be restarted later.

• The checkpoint contains not only the memory image, but also the resource state, in other words, which resources are currently
assigned to the process.

• To be most effective, new checkpoints should not overwrite old ones but should be written to new files, so as the process executes,
a whole sequence accumulates.

• When a deadlock is detected, it is easy to see which resources are needed. To do the recovery, a process that owns a needed
resource is rolled back to a point in time before it acquired that resource by starting at one of its earlier checkpoints.

• All the work done since the checkpoint is lost (e.g., output printed since the checkpoint must be discarded, since it will be printed
again).

• In effect, the process is reset to an earlier moment when it did not have the resource, which is now assigned to one of the
deadlocked processes. If the restarted process tries to acquire the resource again, it will have to wait until it becomes available.
 Recovery through Killing Processes
 One possibility is to kill a process in the cycle. With a little luck, the other processes will be able to continue. If this does not
help, it can be repeated until the cycle is broken.

 Alternatively, a process not in the cycle can be chosen as the victim in order to release its resources.

 In this approach, the process to be killed is carefully chosen because it is holding resources that some process in the cycle needs.

 Example: one process might hold a printer and want a plotter, with another process holding a plotter and wanting a printer.
These two are deadlocked. A third process may hold another identical printer and another identical plotter and be happily
running. Killing the third process will release these resources and break the deadlock involving the first two. Where
possible, it is best to kill a process that can be rerun from the beginning with no ill effects.

 For example, a compilation can always be rerun because all it does is read a source file and produce an object file. If it is killed
partway through, the first run has no influence on the second run.

 On the other hand, a process that updates a database cannot always be run a second time safely. If the process adds 1 to some field
of a table in the database, running it once, killing it, and then running it again will add 2 to the field, which is incorrect.
Safe and Unsafe States
• In Fig. 6-9(a) we have a state in which A has three instances of the resource but may need as many as nine eventually. B
currently has two and may need four altogether, later. Similarly, C also has two but may need an additional five. A total
of 10 instances of the resource exist, so with seven resources already allocated, three there are still free.
• The state of Fig. 6-9(a) is safe because there exists a sequence of allocations that allows all processes to complete.
Namely, the scheduler can simply run B exclusively, until it asks for and gets two more instances of the resource,
leading to the state of Fig. 6-9(b). When B completes, we get the state of Fig. 6-9(c). Then the scheduler can run C,
leading eventually to Fig. 6-9(d). When C completes, we get Fig. 6-9(e). Now A can get the six instances of the resource
it needs and also complete.
• Now suppose we have the initial state shown in Fig. 6-10(a), but this time A requests and gets another resource, giving Fig. 6-10(b). Can we
find a sequence that is guaranteed to work? Let us try. The scheduler could run B until it asked for all its resources, as shown in Fig. 6-
10(c). Eventually, B completes and we get the state of Fig. 6-10(d). At this point we are stuck.
• We only have four instances of the resource free, and each of the active processes needs five. There is no sequence that guarantees
completion. Thus, the allocation decision that moved the system from Fig. 6-10(a) to Fig. 6-10(b) went from a safe to an unsafe state.
Running A or C next starting at Fig. 6-10(b) does not work either. In retrospect, A’s request should not have been granted. It is worth noting
that an unsafe state is not a deadlocked state.
• Thus, the difference between a safe state and an unsafe state is that from a safe state the system can guarantee that all processes will finish;
from an unsafe state, no such guarantee can be given
Deadlock avoidance
Solve
DEADLOCK PREVENTION
• Attacking the Mutual-Exclusion Condition
• If no resource were ever assigned exclusively to a single process, we would never have deadlocks. For data, the
simplest method is to make data read only, so that processes can use the data concurrently.
• However, it is equally clear that allowing two processes to write on the printer at the same time will lead to chaos. By
spooling printer output, several processes can generate output at the same time.
• In this model, the only process that actually requests the physical printer is the printer daemon. Since the daemon never
requests any other resources, we can eliminate deadlock for the printer.
• If the daemon is programmed to begin printing even before all the output is spooled, the printer might lie idle if an output
process decides to wait several hours after the first burst of output. For this reason, daemons are normally programmed to
print only after the complete output file is available. However, this decision itself could lead to deadlock.
• What would happen if two processes each filled up one half of the available spooling space with output and neither was
finished producing its full output? In this case, we would have two processes that had each finished part, but not all, of
their output, and could not continue. Neither process will ever finish, so we would have a deadlock on the disk.
• Avoid assigning a resource unless absolutely necessary, and try to make sure that as few processes as possible may
actually claim the resource.
• Attacking the Hold-and-Wait Condition
• One way to achieve this goal is to require all processes to request all their resources before starting execution.
• If everything is available, the process will be allocated whatever it needs and can run to completion. If one or more
resources are busy, nothing will be allocated and the process will just wait.
• An immediate problem with this approach is that many processes do not know how many resources they will need until
they have started running.
• In fact, if they knew, the banker’s algorithm could be used. Another problem is that resources will not be used optimally
with this approach. Take, as an example, a process that reads data from an input tape, analyzes it for an hour, and then
writes an output tape as well as plotting the results. If all resources must be requested in advance, the process will tie up the
output tape drive and the plotter for an hour.
• The system then preallocates all resources immediately and does not release them until they are no longer needed by the
job. While this method puts a burden on the programmer and wastes resources, it does prevent deadlocks.
• A slightly different way to break the hold-and-wait condition is to require a process requesting a resource to first
temporarily release all the resources it currently holds. Then it tries to get everything it needs all at once.
• Attacking the No-Preemption Condition

• If a process has been assigned the printer and is in the middle of printing its output, forcibly taking away the printer
because a needed plotter is not available is tricky at best and impossible at worst. However, some resources can be
virtualized to avoid this situation.

• Spooling printer output to the disk and allowing only the printer daemon access to the real printer eliminates deadlocks
involving the printer, although it creates a potential for deadlock over disk space. With large disks though, running out of
disk space is unlikely.

• However, not all resources can be virtualized like this.

• For example, records in databases or tables inside the operating system must be locked to be used and therein lies the
potential for deadlock.
• Attacking the Circular Wait Condition
• One way is simply to have a rule saying that a process is entitled only to a single
resource at any moment. If it needs a second one, it must release the first one.
For a process that needs to copy a huge file from a tape to a printer, this
restriction is unacceptable.
• Another way to avoid the circular wait is to provide a global numbering of all
the resources, as shown in Fig. 6-13(a). Now the rule is this: processes can
request resources whenever they want to, but all requests must be made in
numerical order. A process may request first a printer and then a tape drive, but it
may not request first a plotter and then a printer. With this rule, the resource
allocation graph can never have cycles.
Let us see why this is true for the case of two processes, in Fig. 6-13(b). We can get
a deadlock only if A requests resource j and B requests resource i. Assuming i and j
are distinct resources, they will have different numbers. If i > j, then A is not
allowed to request j because that is lower than what it already has. If i < j, then B is
not allowed to request i because that is lower than what it already has. Either way,
deadlock is impossible.
Question1. What will be the content of the Need matrix?

Question2. Is the system in a safe state? If Yes, then what is the safe sequence?
Question3. What will happen if process P1 requests one additional instance of resource type A and two
instances of resource type C?