1. Chapter 7.1: Deadlocks

2. Chapter 7: Deadlocks Chapter 7.1 The Deadlock Problem System Model
Deadlock Characterization
Methods for Handling Deadlocks
Deadlock Prevention
Chapter 7.2
Deadlock Avoidance
Deadlock Detection
Recovery from Deadlock

3. Chapter Objectives
To develop a description of deadlocks, which prevent sets of concurrent processes from completing their tasks
To present a number of different methods for preventing or avoiding deadlocks in a computer system.

4. The Deadlock Problem
The difficulty in a multiprogramming environment is simply that we have many processes in concurrent and sometime simultaneous execution.
Oftentimes these tasks need to access resources which, by their very nature are shared.
Essentially, when one process holds some resources and is awaiting other resources, which are held by another process perhaps awaiting the same resources currently held by the initial process, we have deadlock.
A little more formally, deadlock may be described as a set of blocked processes each holding a resource and waiting to acquire a resource held by another process in the set.
Example
System has two tape drives.
P1 and P2 each hold one tape drive and each needs another one.

5. The Notion of Deadlock
The requesting and releasing of resources are system calls – not interrupts.
Requesting and releasing of resources not managed by the operating system can be handled by
wait() and signal() on semaphores or
through the acquiring and releasing of a mutual exclusion locks, often called mutex locks.
For shared resources that are managed by the kernel, the kernel checks to make sure that the process or thread has requested and has been allocated the resource.
Often system tables are employed to keep track of each resource in the system.
Many examples of using these tables later in this chapter.
Resource allocation tables (graphs) indicate
numbers and classes of resources,
whether they are allocated or free, and if allocated,
to which process allocated;
if a process / thread is awaiting for a resource, a process is generally queued up awaiting the resource to be freed up.

6. The Notion of Deadlock - more
It is easy to understand how deadlock can occur.
But for an efficiently running computing system, we must be concerned over resource allocation and resource release.
Important to note that resources may / often are physical devices such as disk drives, printers, tape drives, etc.
In many cases, we have identical devices put into ‘categories.’
In other cases, shared resources may be considered ‘logical;’ that is, files, semaphores, and even inter-process communication facilities (mailboxes, sockets, ...)

7. Bridge Crossing Example
Traffic only in one direction.
Each section of a bridge can be viewed as a resource.
If a deadlock occurs, it can be resolved if one car backs up (preempt resources and rollback).
Several cars may have to be backed up if a deadlock occurs.
Starvation is possible.

8. System Model
You will see a lot of the following notation within this chapter:
Ri for some resource, Pi for some process, Available resources (a vector), Max, a matrix capturing processes and resources allocated to each process, Allocated (matrix – resources allocated to each process), Need (another similar matrix) and more.
Resource types R1, R2, . . ., Rm
May refer to: CPU cycles, memory space, I/O devices
Each resource type Ri has Wi instances.
Each process utilizes a resource as follows:
request
use
Release
But there’s also ‘resource needs’ ‘resources allocated’ ‘available resources for a given class of resources’ etc.
So the controlling of deadlock is often complex.

9. Deadlock Characterization
Deadlock is a serious condition where processes never complete their execution and where system resources are tied up preventing jobs from finishing and other jobs from even starting.
Deadlock can arise if four conditions hold simultaneously.
Mutual exclusion: only one process at a time can use a resource.
that is, the resource is not sharable. Enough said.
Hold and wait: a process holding at least one resource 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.
This, of course, is a bigee, since the process holding the resource will not release the resource until it acquires additional resources so it can finish its execution. So, ….
Circular wait: there exists a set {P0, P1, …, P0} of waiting processes such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2, …, Pn–1 is waiting for a resource that is held by Pn, and P0 is waiting for a resource that is held by P0.
While all four of these are not mutually exclusive, they must all hold!!
Let’s get to the fun stuff… 

10. Resource-Allocation Graph
Assume we have a set of vertices V and a set of edges E.
V is partitioned into two types:
P = {P1, P2, …, Pn}, the set consisting of all the processes in the system.
R = {R1, R2, …, Rm}, the set consisting of all resource types in the system.
Note that this ‘n’ (number of all processes) and m (number of resource types) is used repeatedly within this chapter.
We have a
‘request edge’ – directed edge P1  Rj Process i requests Resource j
And an
‘assignment edge’ – directed edge Rj  Pi Resource i is assigned to Process j

11. Resource-Allocation Graph (Cont.)
Process
Resource Type with 4 instances
Pi requests instance of Rj
Pi is holding an instance of Rj Note: a specific instance is directed to the ‘holding’ process. Pi Rj Pi Rj

12. Example of a Resource Allocation Graph
We have three processes, four
categories of resources (R2 and R4 have multiple instances of that resource type).
Can see we have one instance of type R1 and
R3 and two instances of resource type R2 and
three instances of resource type R4.
Can also see P1 has requested R1 which is
allocated to P2, which also requests R3, which
is allocated to P3.
Both resources of type R2 are allocated to P1 and P2.
The three instances of R4 are not allocated.

13. Resource Allocation Graph With A Deadlock
Our objective is to ensure that there are no cycles.
If there are no cycles, then no processes are deadlocked.
If a cycle exists, then a deadlock ‘may’ exist.
Now if there is only one instance each of a specific resource and there is a cycle, we DO have deadlock.
The graph will point this out clearly.
A cycle in such a graph is both necessary and sufficient condition for a deadlock.
But if each resource has a number of instances, a cycle does not necessarily mean there is a deadlock.
Here, a cycle is necessary but not necessarily sufficient for a deadlock.

14. Resource Allocation Graph With A Deadlock
Here, let’s assume we have P3 requesting an instance
of R2.
No instance of R2 is available.
So we have a request edge from P3 to R2 is added
At this time, there are two cycles:
P1  R1  P2  R3  P3  R2  P1
And
P2  R3  P3  R2  P2.
You can readily see this two cycles and P1, P2, and P3
are deadlocked.
P2 is waiting for R3 which is allocated to P3 which is
waiting for either P1 or P2 to release R2.
Further, P1 is waiting for P2 to release R1, but it won’t
do so until it gets R3 (which is allocated to P3)
(Note that without adding the request for R2 from P3
we do not have any cycles!)

15. Resource Allocation Graph With A Cycle But No Deadlock
But consider this graph with no deadlock…
Here, P1  R1  P3  R2  P1.
(p1 requests r1 which is allocated to p3 which
requests r2, which is allocated to p1)
Looking at this one, we see P1 is waiting on
either P2 or P3 to release R1.
It appears that there is a deadlock.
There is no deadlock because P4 can
release an instance of R2, which can be
allocated to P3. This would break up the
cycle.
So we conclude that if there is a cycle, there
may or may not be deadlock where there
are multiple instances of resources…

16. Basic Facts If graph contains no cycles  no deadlock.
If graph contains a cycle 
if only one instance per resource type, then deadlock.
if several instances per resource type, possibility of deadlock.

17. Deadlock – many faces We can: Prevent deadlock Avoid deadlock
Detect deadlock
Recover from deadlock.
Let’s consider all these…

18. Methods for Handling Deadlocks
Three ways to handle deadlock – any one will do…
 Ensure that the system will never enter a deadlock state.
Deadlock Prevention
 Allow the system to enter a deadlock state and then recover.
Deadlock Detection and Deadlock Recovery
 Ignore the problem and pretend that deadlocks never occur in the system; used by most operating systems, including UNIX.
Often done!!!
Deadlock becomes noticeable due to system performance degradation.
Can see system grind to a halt.
Since system deadlock occurs so infrequently, rather than incur the tremendous overhead of consistently attempting to ferret out the potential for deadlock, which isn’t cheap, it may be better to ignore it and simply monitor performance of the computing system.
Let’s look at these though…

19. Deadlock Prevention
Recall that there were four requirements for deadlock to occur.
All four had to hold for deadlock to occur.
Clearly, if we can ensure at least one cannot occur, we can eliminate the
possibility of deadlock. Sounds simple…  Consider the first two…
1. Mutual Exclusion – not required for sharable resources;
E.g. read only files. These cannot result in deadlock. No process needs to wait for a sharable resource.
Must hold for nonsharable resources.
e.g. sharing a printer
Ensuring this does not hold eliminates the possibility of deadlock.
Probably not the best choice!!!!!
2. Hold and Wait – must guarantee that whenever a process requests a resource, it does not hold any other resources.
One approach is that when a process issues its request for resources, all its resources must be granted before the process begins execution.
A second approach allows process to request resources only when the process has none. (therefore it cannot hold some, waiting on others.)
Both of these approaches (protocols) may result in low resource utilization since resources may not be used for a long time; secondly, starvation possible. A process needing several ‘popular’ resources may never get them all and hence never start to execute!

20. Deadlock Prevention (Cont.)
3. No Preemption of resources already allocated… –
So, to disallow this from happening:
If a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held are released.
Preempted resources are added to the list of resources for which the process is waiting.
Process will be restarted only when it can regain its old resources, as well as the new ones that it is requesting.
There is an alternative to this approach.
Of course, if all the resources requested by a process are available, we simply allocate them to this process. No big deal.
But if ‘some’ of the resources are available, we look to those that are not currently available. If they are being held by some other process which is waiting for other resources, then we can preempt these resources from this other process and allocate them to the waiting process.
Further, if the resources desired are both not available and not available by preempting them from some other waiting process, then this requesting process must wait.
Of course, the resources it is ‘holding’ may be preempted by some other process that needs them to continue, as described in the alternative above.

21. Deadlock Prevention (Cont.)
4. Circular Wait – The notion of a circular wait is clear…
But to prevent deadlock, if we prevent only this possibility of a circular wait, then (because only one of the four need to be prevented from occurring), then we can prevent deadlock.
Perhaps the most straightforward way to prevent a circular wait is to simply impose some kind of a total ordering of resources by ‘resource type.’
We Are suggesting requesting resources in a certain ‘order.’
So a requesting process will request all the resources it needs at one time by a specific type of resource.
Once allocated, this requesting process can then request all the instances of another resource (in an enumerated list of resource types). This is a single request for n resources of type Ri
As a further alternative (since processes don’t may often not need all their resources at one time), a process may request a resource type not previously allocated.
And, if this resource type is ‘lesser’ by enumeration, that is type R(i) < R(j), then it must release those resources of type R(j).
Imposing a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration will prevent a circular wait.
By extension, no deadlock may occur.
Note that imposing an ordering on resources doesn’t solve the problem, The application developer must write programs that subscribe to this ordering!!

22. End of Chapter 7.1