Chapter 7.1: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 7: Deadlocks Chapter 7.1 The Deadlock Problem System

Chapter 7.1: DeadlocksChapter 7.1: Deadlocks

7.2 Silberschatz, Galvin and Gagne ©2005Operating System Concepts

Chapter 7: DeadlocksChapter 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


Chapter ObjectivesChapter 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.


The Deadlock ProblemThe 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.


The Notion of DeadlockThe 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.


The Notion of Deadlock - moreThe 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, ...)


Bridge Crossing ExampleBridge 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.


System ModelSystem 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.


Deadlock CharacterizationDeadlock Characterization

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…

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.


Resource-Allocation GraphResource-Allocation Graph

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

Assume we have a set of vertices V and a set of edges E.


Resource-Allocation Graph (Cont.)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

Pi

Rj

Rj


Example of a Resource Allocation GraphExample 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.


Resource Allocation Graph With A DeadlockResource 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.


Resource Allocation Graph With A DeadlockResource 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 P1AndP2 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!)


Resource Allocation Graph With A Cycle But No DeadlockResource 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…


Basic FactsBasic 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.


Deadlock – many facesDeadlock – many faces

We can:

Prevent deadlock

Avoid deadlock

Detect deadlock

Recover from deadlock.

Let’s consider all these…


Methods for Handling DeadlocksMethods 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…


Deadlock PreventionDeadlock Prevention

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!

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…


Deadlock Prevention (Cont.)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.


Deadlock Prevention (Cont.)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!!

End of Chapter 7.1End of Chapter 7.1

Documents

Chapter 7.1: Deadlocks. 7.2 Silberschatz, Galvin and Gagne ©2005 Operating System Concepts Chapter 7: Deadlocks Chapter 7.1 The Deadlock Problem System