Deadlock Prevention

And
Deadlock Avoidance

Operating System

Ibrar Afzal

IT Department HU Mansehra 1
 Deadlock Prevention
 Do not permit one of the four necessary conditions to occur Deadlock.
Mutual exclusion
Several processes cannot simultaneously share a single resource
 Automatically holds for printers and other non-sharables.

 Shared entities (read only files) don't require mutual exclusion (and aren’t
susceptible to deadlock.)
 Prevention not possible, since a number of devices are basically non-sharable.
 
 

2
 Deadlock Prevention
Do not permit one of the four necessary conditions to occur Deadlock.  
Hold and wait:
 Grant resources on “all or none” basis.
 Process request be granted all of the resources it needs at once i.e. prior to execution
 Disallow a process from requesting resources whenever it has previously allocated
resources.
 Serious waste of resources
 Resources are allotted at creation time but will be used after several hours.
 All the required resources may not be available at once.
  Indefinite postponement (starvation)

3
 Deadlock Prevention

 Do not allow one of the four conditions to occur.

 
No preemption:
 

If a request is being made a process already owner of some resources then then immediately don’t
allocate new requested resources to a process until it not released the hold resources.
After release of resource ,already preempted resources will be added to the list of resources for which
the process is waiting
Process will be restarted only when it can get back its old resources, as well as the new ones that it is
requesting

4
 Deadlock Prevention

 Do not allow one of the four conditions to occur.

Circular wait:
The circular-wait condition can be prevented by defining a linear ordering of
resource types.
If a process has been allocated resources of type R, then it may subsequently request
only those resources of types following R in the ordering.
Circular-wait prevention may be inefficient
Slowing down processes and denying resource access unnecessarily.

5
 Deadlock Prevention

Do you think it’s a better technique?

NO
 It may cause a decrease in utilization and/or resources.
 BUT Prevention is generally the easiest to implement.

6
 Deadlock Avoidance

If we have prior knowledge of how resources will be requested, it's possible to

determine if we are entering an "unsafe" state.
 
Possible states are:
 
Deadlock No forward progress can be made.
 
Unsafe state A state that may allow deadlock.
 
Safe state A state is safe if a sequence of processes exist such that there are
enough resources for the first to finish, and as each finishes and
releases its resources there are enough for the next to finish.
 

7
 Deadlock Avoidance

The rule is simple:

If a request allocation would cause an unsafe state, do not
honor that request.
 
NOTE: All deadlocks are unsafe, but all unsafes states are NOT
deadlocks.

8
 Deadlock Avoidance

UNSAFE
SAFE
DEADLOCK

O.S. can avoid

Only with luck will
processes avoid deadlock.
deadlock.

9
 Deadlock Avoidance

Let's suppose a very straightforward model:

each process declare its maximum needs.
 In this case, algorithms exist that will ensure that
no unsafe state is reached.
 Maximum needs does NOT mean it must use that many resources
 simply that it might do so under some circumstances.
 

10
 Deadlock Avoidance

Safety Algorithm
A method used to determine if a particular state is safe. It's safe if there exists a
sequence of processes such that for all the processes, there’s a way to avoid deadlock:

The algorithm uses these variables:

 
Need[I] – the remaining resource needs of each process.
Work - Temporary variable – how many of the resource are currently available.
Finish[I] – flag for each process showing we’ve analyzed that process or not.

need <= available + allocated[0] + .. + allocated[I-1]  Sign of success

 
Let work and finish be vectors of length m and n respectively.
 

11
 Deadlock Avoidance

Safety Algorithm
1. Initialize work = available
Initialize finish[i] = false, for i = 1,2,3,..n
 
2. Find an i such that:
finish[i] == false and need[i] <= work
 
If no such i exists, go to step 4.
 
3. work = work + allocation[i]
finish[i] = true
goto step 2
 
4. if finish[i] == true for all i, then the system is in a safe state.

12
 Deadlock Avoidance
Safety Algorithm
Do these examples:
Consider a system with: five processes, P0  P4, three resource types, A, B, C.
Type A has 10 instances, B has 5 instances, C has 7 instances.
At time T0 the following snapshot of the system is taken.
 

Max Needs = allocated + can-be-requested

 Alloc   Req   Avail 

Is the system
in a safe state? A B C A B C A B C
P0 0 1 0 7 4 3 2 3 0
P1 3 0 2 0 2 0
P2 3 0 2 6 0 0
P3 2 1 1 0 1 1
P4 0 0 2 4 3 1
13
 Deadlock Avoidance
Safety Algorithm
Do these examples:
Now try it again with only a slight change in the state of P0.
P0 requests two more of type B.
Request by P0 = (0,2,0).
 

 Alloc   Req   Avail 

A B C A B C A B C
P0 0 3# 0 7 4 3 2 1# 0
P1 3 0 2 0 2 0
Can the
request be P2 3 0 2 6 0 0
granted? P3 2 1 1 0 1 1
P4 0 0 2 4 3 1

14
 Deadlock Avoidance

Banker's Algorithm
 Resource allocation system with multiple instances of each resource type  
 When a new process enters the system, it must declare the maximum
 number of instances of each resource type that it may need.
 This number may not exceed the total number of resources in the system.
 When a user requests set of resources, the system must determine whether the
allocation of these resources will leave the system in a safe state.
 If it will, the resources are allocated; otherwise, the process must wait until some
other process releases enough resources.

15
 Deadlock Avoidance
Banker's Algorithm
 

16
 Deadlock Recovery

Banker's Algorithm
 

17
 Deadlock Avoidance

Banker's Algorithm
 

7: Deadlocks
18
 Deadlock Avoidance
Banker's Algorithm
 

7: Deadlocks
19
 

Thanks

20