DEADLOCKS

1
DEADLOCKS
2
Introduction

• In a computer system, we have a finite number of
  resources to be distributed among a number of
  competing processes.
• System resources are classified into
• Physical Resources
• Logical Resources

3
Introduction continue

• In a computer system, we have a finite number of
  resources to be distributed among a number of
  competing processes.
• System resources are classified into
• Physical Resources
• Logical Resources

• Printers
• Tape drivers
• Memory space
• CPU cycles

4
Introduction continue

• In a computer system, we have a finite number of
  resources to be distributed among a number of
  competing processes.
• System resources are classified into
• Physical Resources
• Logical Resources

• Files
• Semaphores

5
Introduction continue
A process must request a resource before using it
and release the resource after using it. The
number of resources requested can not exceed the
total number of resources available in the system.
6
Introduction continue

• In a normal operation, a process may utilize a
  resource in the following sequence
• Request the resource
• Use the resource
• Release the resource

7
Introduction continue

• In a normal operation, a process may utilize a
  resource in the following sequence
• Request
• Use
• Release

If the request can not be immediately granted,
then the requesting process must wait until it
can get the resource.
8
Introduction continue

• In a normal operation, a process may utilize a
  resource in the following sequence
• Request
• Use
• Release

The requesting process can operate on the
resource.
9
Introduction continue

• In a normal operation, a process may utilize a
  resource in the following sequence
• Request
• Use
• Release

The process releases the resource after using it.
10
Introduction continue
The OS is responsible for making sure that the
requesting process has been allocated the
resource. Request and release of resources can be
accomplished through the wait and signal
operations on semaphores. A system table records
whether each resource is free or allocated, and
if allocated, to which process. If a process
requests a resource that is currently allocated
to another process, it can be added to a queue of
processes waiting for this resource.
11
Deadlock Situation
In a multi-programming environment, several
processes may compete for a fixed number of
resources. A process requests resources and if
the resources are not available at that time, it
enters a wait state. Waiting processes may never
again change state, because the resources they
have requested are held by other waiting
processes. This situation is called deadlock.
12
Deadlock Situation
P 1
Printer
P 2
Scanner
13
Deadlock Situation
Consider a system with one printer and one
scanner. Process P1 request the printer and
process P2 requests the scanner. Both requests
are granted. Now P1 requests the scanner (without
giving up the printer) and P2 requests the
printer (without giving up the scanner). Neither
request can be granted so both processes enter a
deadlock situation.
14
Deadlock Situation
P 1
Printer
P 2
Scanner
15
Deadlock - Definition
A deadlock is a situation where a group of
processes is permanently blocked as a result of
each process having acquired a set of resources
needed for its completion and having to wait for
release of the remaining resources held by others
thus making it impossible for any of the
deadlocked processes to proceed. Deadlocks can
occur in concurrent environments as a result of
the uncontrolled granting of the system resources
to the requesting processes.
16
Deadlock - Definition
A set of process is in a deadlock state if each
process in the set is waiting for an event that
can be caused by only another process in the
set. Each member of the set of deadlock
processes is waiting for a resource that can be
released only by a deadlock process.
17
Deadlock Characterization

• Necessary Conditions
• A deadlock situation can arise if the following
  four conditions hold simultaneously in a system.
• Mutual Exclusion
• Hold and Wait
• No Preemption
• Circular Wait

18
Deadlock Characterization

• Necessary Conditions
  Continue
• Mutual Exclusion
• At least one resource must be held in a
  non-sharable mode that is, only one process at a
  time can use the resource. If another process
  requests that resource, the requesting process
  must be delayed until the resource has been
  released.

19
Deadlock Characterization

• Necessary Conditions
  Continue
• Hold and Wait
• A process must be holding at least one resource
  and waiting to acquire additional resources that
  are currently held by other processes.

20
Deadlock Characterization

• Necessary Conditions
  Continue
• No Preemption
• Resources already allocated to a process cannot
  be preempted that is, a resource can be released
  only voluntarily by the process holding it,
  after process has completed its task.

21
Deadlock Characterization

• Necessary Conditions
  Continue
• Circular Wait
• A set P0, P1, , Pn of waiting processes must
  exist 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 Pn is waiting for a
  resource that is held by P0.
• The processes in the system form a circular list
  or chain where each process in the list is
  waiting for a resource held by the next process
  in the list.

22
Deadlock Situation
P 1
P 2
P 1
i
i
R1
R2
P 2
i
i
R1
R2
Holding a resource
Requesting a resource
Deadlock situation
Graphic representation of Resource Allocation
23
Resource-Allocation Graph
Resource-allocation graph is used to described
the deadlock. This graph consists of a set of
vertices V and a set of edges E. The set vertices
V is partitioned into two different types of
nodes P P1, P2, , Pn, the set consisting of
all active processes in the system, and R R1,
R2, , Rm, the set consisting of all resource
types in the system.
24
Resource-Allocation Graph continue
A directed edge from resource type Rj to process
Pi is denoted by Rj gPi it signifies that an
instance of resource type Rj has been allocated
to process Pi . A directed edge Pi gRj is called
a request edge and a directed edge Rj gPi is
called an assignment edge.
25
Resource-Allocation Graph continue
Process node is represented by circles. Resource
node is represented by rectangles. For each
instances of a resource type, there is a dot in
the resource node rectangle.
P 1
R1
i i
R2
26
Resource-Allocation Graph continue
A request edge points to only the square , where
as an assignment edge must also designate one of
the dots in the square.
i
i
R1
R3
P 1
P 2
P 3
i i
i i i
R4
R2
27
Resource-Allocation Graph continue
When process Pi requests an instance of resource
type Rj, a request edge is inserted in the
resource allocation graph.
i
i
R1
R3
P 1
P 2
P 3
i i
i i i
R4
R2
28
Resource-Allocation Graph continue
When this requests can be fulfilled the request
edge is instantaneously transformed to an
assignment edge.
i
i
R1
R3
P 1
P 2
P 3
i i
i i i
R4
R2
29
Resource-Allocation Graph continue
When the process no longer needs access to the
resource it releases the resource, and as a
result the assignment edge is deleted.
i
i
R1
R3
P 1
P 2
P 3
i i
i i i
R4
R2
30
Resource-Allocation Graph continue
The resource-allocation graph depicts the
following
i
i
R1
R3
P 1
P 2
P 3

• The sets P, R, and E
• P P1, P2, , Pn
• R R1, R2, , Rm
• E P1 gR1, P2 gR3, R1 gP2, R2 gP2, R2 gP1,
  R3 gP3

i i
i i i
R4
R2
31
Resource-Allocation Graph continue
The resource-allocation graph depicts the
following
i
i
R1
R3
P 1
P 2
P 3

• Resource instances
• One instance of resource type R1
• Two instances of resource type R2
• One instance of resource type R3
• Three instances of resource type R4

i i
i i i
R4
R2
32
Resource-Allocation Graph continue
The resource-allocation graph depicts the
following
Process states
i
i
R1
R3
Process P1 is holding an instance of resource
type R2 , and is waiting for an instance of
resource type R1 .
P 1
P 2
P 3
i i
i i i
R4
R2
33
Resource-Allocation Graph continue
The resource-allocation graph depicts the
following
Process states
i
i
R1
R3
Process P1 is holding an instance of resource
type R2, and is waiting for an instance of
resource type R1.
Process P2 is holding an instance of resource
types R1 and R2, and is waiting for an instance
of resource type R3 .
P 1
P 2
P 3
i i
i i i
R4
R2
34
Resource-Allocation Graph continue
The resource-allocation graph depicts the
following
Process states
i
i
R1
R3
Process P1 is holding an instance of resource
type R2, and is waiting for an instance of
resource type R1.
Process P2 is holding an instance of resource
types R1 and R2, and is waiting for an instance
of resource type R3 .
P 1
P 2
P 3
Process P3 is holding an instance of resource
type R3 .
i i
i i i
R4
R2
35
Resource-Allocation Graph continue
Tips to check deadlock
i
i
R1
R3
If no cycle exists in the resource allocation
graph, there is no deadlock.
P 1
P 2
P 3
i i
i i i
R4
R2
36
Resource-Allocation Graph continue
Tips to check deadlock
i
i
R1
R3
If there is a cycle in the graph and each
resource has only one instance, then there is a
deadlock. Here a cycle is a necessary and
sufficient condition for deadlock.
P 1
P 2
P 3
i
i i i
R4
R2
37
Resource-Allocation Graph continue
Tips to check deadlock
If there is a cycle in the graph and each
resource has more than one instance, there may or
may not be a deadlock. A cycle may be broken if
some process outside the cycle has a resource
instance that can break the cycle. Therefore, a
cycle in the resource allocation graph is a
necessary but not sufficient condition for
deadlock, when multiple resource instances are
considered.
38
Resource-Allocation Graph continue
Tips to check deadlock
P 2
i i
R1
If there is a cycle in the graph and each
resource has more than one instance, there may or
may not be a deadlock. A cycle may be broken if
some process outside the cycle has a resource
instance that can break the cycle. Therefore, a
cycle in the resource allocation graph is a
necessary but not sufficient condition for
deadlock, when multiple resource instances are
considered.
P 1
P 3
i i
P 4
R2
39
Handling Deadlocks

• Possible strategies to deal with deadlocks
• Deadlock Prevention
• Deadlock Avoidance
• Deadlock Detection and Recovery

40
Handling Deadlocks continue

• Possible strategies to deal with deadlocks
• Deadlock Prevention
• Deadlock Avoidance
• Deadlock Detection and Recovery

Is a set methods for ensuring that at least one
of the necessary conditions cannot hold. These
methods prevent deadlocks by constraining how
requests for resources can be made.
41
Handling Deadlocks continue

• Possible strategies to deal with deadlocks
• Deadlock Prevention
• Deadlock Avoidance
• Deadlock Detection and Recovery

DA requires that the operating system be given in
advance additional information concerning which
resources a process will request and use during
its lifetime. With this knowledge, we can decide
for each request whether or not the process
should wait.
42
Handling Deadlocks continue

• Possible strategies to deal with deadlocks
• Deadlock Prevention
• Deadlock Avoidance
• Deadlock Detection and Recovery

Here the system can provide an algorithm that
examines the state of the system to determine
whether a deadlock has occurred and an algorithm
to recover from the deadlock.
43
Deadlock Prevention

• We can prevent the occurrence of a deadlock by
  ensuring that at least one of the four necessary
  conditions can not hold.
• Mutual Exclusion
• Hold and Wait
• No Preemption
• Circular Wait

44
Deadlock Prevention continue
Mutual Exclusion Shareable resources do not
require mutually exclusive access, and thus
cannot be involved in a deadlock.
45
Deadlock Prevention continue

• Hold and Wait
• When a process requests a resource, it does not
  hold any other resources. Two protocols
• Requires each process to request and be allocated
  all its resources before it begins execution.
• Allows a process to request resources only when
  the process has none.

46
Deadlock Prevention continue

• Hold and Wait
• When a process requests a resource, it does not
  hold any other resources. Two protocols
• Requires each process to request and be allocated
  all its resources before it begins execution.
• Allows a process to request resources only when
  the process has none.

A process may request some resources and use
them. However it must release all the resources
that is currently allocated before it can request
any additional resources.
47
Deadlock Prevention continue
No Preemption If a process is holding some
resources and requests another resource that
cannot be immediately allocated to it, then all
resources currently being held are preempted. The
process will be restarted only when it can regain
its old resources, as well as the new ones that
is requesting.
48
Deadlock Prevention continue
No Preemption If a process requests some
resources, we first check whether they are
available. If they are, we allocate them. If they
are not available, we check whether they are
allocated to some other process that is waiting
for additional resources. If so, we preempt the
desired resources from the waiting process and
allocate them to the requesting process. If the
resources are not either available or held by a
waiting process, the requesting process must
wait. While it is waiting, some of its resources
may be preempted, but only if another process
request them. A process can be restarted only
when it is allocated the new resources it is
requesting and recovers any resources that were
preempted while it was waiting.
49
Deadlock Prevention continue
Circular Wait One way to ensure that circular
wait never holds is to impose a total ordering of
all resource types, and to require that each
process requests resources in an increasing order
of enumeration.
50
Deadlock Prevention continue
Circular Wait Each process can request resources
only in an increasing order of enumeration. That
is, a process can initially request any number of
instances of a resource type, say Ri. After that,
the process can request instances of resource
type Rj if and onlyif F(Rj) gt F(Ri).
51
Deadlock Prevention continue
Circular Wait Alternatively, whenever a process
requests an instance of resource type Rj, it has
released any resources Ri such that F(Ri) gt
F(Rj).
52
Deadlock Prevention continue
Deadlock prevention algorithms prevent deadlocks
by restraining how request can be made. This
ensures that at least one of the necessary
conditions for deadlock cannot occur. Possible
side effects of preventing deadlocks by this
methods are low utilization and reduced system
throughput.
53
Deadlock Avoidance
Deadlock-Allocation requires that the operating
system be given in advance additional information
concerning which resources a process will request
and use during its lifetime. With this knowledge,
we can decide for each request whether or not the
process should wait.
54
Deadlock Avoidance
Deadlock-Allocation requires that the operating
system be given in advance additional information
concerning which resources a process will request
and use during its lifetime. With this knowledge,
we can decide for each request whether or not the
process should wait. Given a priori information
about the maximum number of resources of each
type that may be requested for each process, it
is possible to construct an algorithm that
ensures the deadlock-avoidance approach.
55
Deadlock Avoidance
Deadlock-Allocation requires that the operating
system be given in advance additional information
concerning which resources a process will request
and use during its lifetime. With this knowledge,
we can decide for each request whether or not the
process should wait. Given a priori information
about the maximum number of resources of each
type that may be requested for each process, it
is possible to construct an algorithm that
ensures the deadlock-avoidance approach. A
deadlock-avoidance algorithm dynamically examines
the resource-allocation state to ensure that a
circular wait condition can never exist. The
resource-allocation state is defined by the
number of available and allocated resources, and
the maximum demands of the processes.
56
Deadlock Avoidance continue
Safe State A state is safe if the system can
allocate resources to each process(up to its
maximum) in some order and still avoid a
deadlock. A system is in a safe state only if
there exists a safe sequence.
57
Deadlock Avoidance continue
Safe State A sequence of processes ltP1, P2, ,
Pngt is a safe sequence for the current allocation
state if, for each Pi, the resources that Pi can
still request can be satisfied by the currently
available resources plus the resources held by
all the Pj, with j lt i.
58
Deadlock Avoidance continue
Safe State In this situation the resources that
process Pi needs are not immediately available,
then Pi can wait until all Pj have finished. When
they have finished, Pi can obtain all of its
needed resources, complete its designated task,
return its allocated resources and terminate.
When Pi terminates, Pi1 can obtain its needed
resources and so on. If no sequence exists, then
the system state is said to be unsafe.
59
Deadlock Avoidance continue
Safe State Consider a system with 12 magnetic
tape drives and 3 processes, P0, P1 and P2.
Maximum need To P0 10 5 P1 4 2 P2
9 2
60
Deadlock Avoidance continue
Safe State Consider a system with 12 magnetic
tape drives and 3 processes, P0, P1 and P2.
Maximum need To P0 10 5 P1 4 2 P2
9 2
At time To, the system is in a safe state
61
Deadlock Avoidance continue
Safe State Now there are 3 free tape drives. The
sequence ltP1, P0, P2gt satisfies the safety
condition. Process P1 can immediately be
allocated all its tape drives and then return
them(the system then will have 5 available tape
drives), then process P0 can get all its tape
drives and return them(then available 10 tape
drives), and finally process P2 could get all its
tape drives.
62
Deadlock Avoidance continue
Safe State A system may go from a safe state to
an unsafe state. Suppose that at time T1, process
P2 requests and is allocated 1 more tape drive.
Then the system is no longer in a safe state,
because at this point only process P1 can be
allocated all its tape drives and process P0 and
P2 have to wait resulting in a deadlock.
63
Deadlock Avoidance continue
Safe State Avoidance algorithms ensure that the
system will always remain in a safe state.
Initially, the system is in a safe state.
Whenever a process requests a resource that is
currently available, the system must decide
whether the resource can be allocated immediately
or whether the process must wait. The request is
granted only if the allocation leaves the system
in safe state.
64
Deadlock Avoidance continue
Safe State Avoidance algorithms ensure that the
system will always remain in a safe state.
Initially, the system is in a safe state.
Whenever a process requests a resource that is
currently available, the system must decide
whether the resource can be allocated immediately
or whether the process must wait. The request is
granted only if the allocation leaves the system
in safe state.
65
Deadlock Avoidance continue
Safe State In this scheme, if a process requests
a resource that is currently available, it may
still have to wait. Thus, resource utilization
may be lower than it would be without
deadlock-avoidance algorithm.
66
Deadlock Avoidance continue

• Resource-Allocation Graph Algorithm
• This graph has three types of edges
• Request edge
• Assignment edge
• Claim edge
• A claim edge Pi gRj indicates that the process Pi
  may request resource Rj at some time in the
  future.

67
Deadlock Avoidance continue
Resource-Allocation Graph Algorithm When process
Pi request resource Rj, the claim edge Pi gRj is
converted to a request edge. When the resource Rj
is released by Pi, the assignment edge Rj gPi is
converted to a claim edge Pi gRj. Before process
Pi starts executing, all its claim edges must
appear in the resource-allocation graph.
68
Deadlock Avoidance continue
Resource-Allocation Graph Algorithm Suppose,
process Pi requests resource Rj. The request can
be granted only if converting the request edge Pi
gRj to an assignment edge Rj gPi does not result
in the formation of a cycle in the
resource-allocation graph. Safety is provided by
the use of cycle detection algorithm.
69
Deadlock Avoidance continue
Resource-Allocation Graph Algorithm
i
R1
If P2 requests R2, we cannot allocate it to P2
even if R2 is currently free, since this action
will create a cycle in the graph.
P 1
P 2
i
R2
70
Deadlock Avoidance continue
Resource-Allocation Graph Algorithm
i
R1
If P2 requests R2, we cannot allocate it to P2
even if R2 is currently free, since this action
will create a cycle in the graph.
P 1
P 2
i
R2
71
Bankers Algorithm
Resource-Allocation Graph Algorithm is not
applicable to a resource allocation system with
multiple instances of each resource
type. Bankers Algorithm deals multiple instances
of each resource type. This algorithm could be
used in a banking system to ensure that the bank
never allocates its available cash such that it
can no longer satisfy the needs of all its
customers.
72
Bankers Algorithm continue
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 resources in the
system.
73
Bankers Algorithm continue
When a user requests a 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.
74
Bankers Algorithm continue

• To implement Bankers algorithm, we need the
  following data structures
• Available
• Max
• Allocation
• Need

75
Bankers Algorithm continue

• To implement Bankers algorithm, we need the
  following data structures
• Available
• Max
• Allocation
• Need

A vector of length m indicates the number of
available resources of each type. If Availablej
k, there are k instances of resource type Rj
available.
76
Bankers Algorithm continue

• To implement Bankers algorithm, we need the
  following data structures
• Available
• Max
• Allocation
• Need

An n x m matrix defines the maximum demand of
each process. If maxi,j k, then process Pi
may request at most k instances of resource type
Rj.
77
Bankers Algorithm continue

• To implement Bankers algorithm, we need the
  following data structures
• Available
• Max
• Allocation
• Need

An n x m matrix defines the number of resources
of each type currently allocated to each process.
If Allocationi,j k, then process Pi is
currently allocated k instances of resource type
Rj.
78
Bankers Algorithm continue

• To implement Bankers algorithm, we need the
  following data structures
• Available
• Max
• Allocation
• Need

An n x m matrix indicates the remaining resource
need of each process. If Needi, j k, then
process Pi may need k more instances of resource
type Rj to complete its tasks. Needi,j
Maxi,j Allocationi,j.
79
Bankers Algorithm continue
We can treat each row in the matrices Allocation
and Need as vectors and refer to them as
Allocationi and Needi. The vector Allocationi
specifies the resources currently allocated to
process Pi the vector Needi specifies the
additional resources that process Pi may still
request to complete its task.
80
Bankers Algorithm continue
Resource-Request Algorithm Let Requesti be the
request vector for process Pi. If Requestij
k, then process Pi wants k instances of resource
type Rj. When a request for resources is made by
process Pi, the following actions are taken
81
Bankers Algorithm continue

• Resource-Request Algorithm continue
• If Requesti Needi, go to step 2. Otherwise,
  raise an error condition, since the process has
  exceeded it maximum claim.
• If Requesti Available, go to step 3.
  Otherwise, Pi must wait, since the resources are
  not available.
• Pretend to have allocated the requested
  resources to process Pi by modifying the state
  as follows
• Available Available Requesti
• Allocationi Allocationi Requesti
• Needi Needi Requesti

82
Bankers Algorithm continue
Resource-Request Algorithm continue If the
resulting resource-allocation state is safe, the
transaction is completed and process Pi is
allocated its resources. However, if the new
state is unsafe, then Pi must wait for Requesti
and the old resource-allocation state is restored.
83
Bankers Algorithm continue

• Safety Algorithm
• Let Work and Finish be vectors of length m and
  n respectively. Initialize Work Available and
  Finishi false for i1,2, , n.
• Find an i such that both
• Finishi false
• Needi Work.
• If no such i exists, go to step 4.
• Work Work Allocationi
• Finishi true
• Go to step 2.
• If Finishi true for all i, then the system is
  an a safe state.

84
Deadlock Detection

• If a system does not employ either a
  deadlock-prevention or a deadlock avoidance
  algorithm, then it should provide
• An algorithm that examines the state of the
  system to determine whether a deadlock has
  occurred.
• An algorithm to recover from the deadlock.

85
Deadlock Detection continue
Single Instance of Each Resource Type If all
resources have only a single instance, then we
can define a deadlock detection algorithm that
uses a variant of the resource-allocation graph,
called a wait-for graph. We obtain this graph
from the resource-allocation graph by removing
the resource nodes and collapsing the appropriate
edges.
86
Deadlock Detection continue
Single Instance of Each Resource Type
(a) Resource-allocation graph (b) Corresponding
wait-for graph
87
Deadlock Detection continue
Single Instance of Each Resource Type An edge
from Pi to Pj in a wait-for graph implies that
process Pi is waiting for process Pj to release
a resource that Pi needs. An edge Pi gPj exists
in a wait-for graph if and only if the
corresponding resource-allocation graph contains
two edges Pi gRq and Rq gPj for some resource
Rq.
88
Deadlock Detection continue
Single Instance of Each Resource Type If there
exists a cycle in wait-for graph, there is a
deadlock in the system, and the processes forming
the part of cycle are blocked in the deadlock. To
take appropriate action to recover from this
situation, an algorithm needs to be called
periodically to detect existence of cycle in
wait-for graph.
89
Deadlock Detection continue
Multiple Instances of a Resource Type When
multiple instances of a resource type exist, the
wait-for graph becomes inefficient to detect the
deadlock in the system. An algorithm which uses
certain data structures similar to ones used in
Bankers algorithm is applied.
90
Deadlock Detection continue

• Multiple Instances of a Resource Type
• The following data structures are used
• Available Resources
• Current Allocation
• Request

91
Deadlock Detection continue

• Multiple Instances of a Resource Type
• The following data structures are used
• Available Resources, A A vector of size q
  stores information about the number of available
  resources of each type.
• Current Allocation
• Request

92
Deadlock Detection continue

• Multiple Instances of a Resource Type
• The following data structures are used
• Available Resources
• Current Allocation, C A matrix of order pxq
  stores information about the number of resources
  of each type allocated to each process. Cij
  indicates the number of resources of type j
  currently held by the process i.
• Request

93
Deadlock Detection continue

• Multiple Instances of a Resource Type
• The following data structures are used
• Available Resources
• Current Allocation
• Request, R A matrix of order pxq stores
  information about the number of resources of each
  type currently requested by each process. Rij
  indicates the number of resources of type j
  currently requested by the process i.

94
Deadlock Detection continue

• Multiple Instances of a Resource Type
• Consider a vector Complete of size p.
• Steps to detect the deadlock
• Initialize CompleteiFalse for all i1,2,3, .,
  p. CompleteiFalse indicates that the ith
  process is still not completed.
• Search for an i, such that CompleteiFalse and
  (RltA), that is , resources currently requested
  by this process is less than the available
  resources. If no such process exists, then go to
  step 4.

95
Deadlock Detection continue

• Multiple Instances of a Resource Type
• Allocate the required resources and let the
  process finish its execution and set
  CompleteiTrue for that process. Go to Step 2.
• If CompleteiFalse for some i, then the system
  is in the state of deadlock and the ith process
  is deadlocked.

96
Deadlock Recovery

• When a detection algorithm determines that a
  deadlock exists, then
• let the operator deal with the deadlock
  manually.
• let the system recover from the deadlock
  automatically.
• There are two options for breaking a deadlock
• to abort one or more processes to break the
  circular wait.
• to preempt some resources from one or more of the
  deadlocked processes.

97
Deadlock Recovery continue

• Process Termination
• There are two methods that can be used for
  terminating the processes to recover from the
  deadlock
• Terminating one process at a time until the
  circular-wait condition is eliminated.
• Terminating all processes involved in the
  deadlock.

98
Deadlock Recovery continue
It involves an over head of invoking a deadlock
detection algorithm after terminating each
process to detect whether circular-wait condition
is eliminated or not, that is, whether any
processes are still deadlocked.

• Process Termination
• There are two methods that can be used for
  terminating the processes to recover from the
  deadlock
• Terminating one process at a time until the
  circular-wait condition is eliminated.
• Terminating all processes involved in the
  deadlock.

99
Deadlock Recovery continue

• Process Termination
• There are two methods that can be used for
  terminating the processes to recover from the
  deadlock
• Terminating one process at a time until the
  circular-wait condition is eliminated.
• Terminating all processes involved in the
  deadlock.

This method will definitely ensure the recovery
of a system from the deadlock. The disadvantage
of this method is that many processes may have
executed for a long time close to their
completion. As a result, the computations
performed till the time of termination are
discarded.
100
Deadlock Recovery continue
Resource Preemption An alternate method to
recover system from the state of deadlock is to
preempt the resources from the processes one by
one and allocate them to other processes until
the circular-wait condition is eliminated.
101
Deadlock Recovery continue

• Resource Preemption
• Steps involved in the preemption of resources
  from processes are
• Select a process for preemption.
• Roll back of the process.
• Prevent starvation.

102
Deadlock Recovery continue

• Resource Preemption
• Steps involved in the preemption of resources
  from processes are
• Select a process for preemption.
• Roll back of the process.
• Prevent starvation.

The choice of resources and processes must be
such that they incur minimum cost to the system.
103
Deadlock Recovery continue
After preempting the resources, the corresponding
process must be rolled backed properly so that it
does not leave the system in an inconsistent
state. Process must be brought to some safe state
from where it can be restarted later. In case no
such safe state can be achieved, the process must
be totally rolled back. Partial rollback is
preferred.

• Resource Preemption
• Steps involved in the preemption of resources
  from processes are
• Select a process for preemption.
• Roll back of the process.
• Prevent starvation.

104
Deadlock Recovery continue

• Resource Preemption
• Steps involved in the preemption of resources
  from processes are
• Select a process for preemption.
• Roll back of the process.
• Prevent starvation.

In case of the selection of a process is based on
the cost factor, it is quite possible that same
process is selected repeatedly for the rollback
leading to the situation of starvation. This can
be avoided by including the number of rollbacks
of a given process in the cost factor.