UNIT-IV

DEADLOCK
UNIT - IV
Deadlocks - System Model, Deadlock Characterization, Methods for
Handling Deadlocks, Deadlock Prevention, Deadlock Avoidance, Deadlock
Detection and Recovery from Deadlock.

Deadlock:
A process requests resources; and if the resources are not available at
that time, the process enters a waiting state. Sometimes, a waiting process is
never again able to change state, because the resources it has requested are
held by other waiting processes. This situation is called a deadlock.
(or)
If a process is unable to change its state indefinitely because the resources
requested by it are being used by another waiting process, then the system is
said to be in a deadlock.
(or)
Deadlock is a situation where two or more processes are waiting for
each other. For example, let us assume, we have two processes P1 and P2.
Now, process P1 is holding the resource R1 and is waiting for the resource
R2. At the same time, the process P2 is having the resource R2 and is
waiting for the resource R1.

So, the process P1 is waiting for process P2 to release its resource and at
the same time, the process P2 is waiting for process P1 to release its
resource. And no one is releasing any resource. So, both are waiting for each
other to release the resource. This leads to infinite waiting and no work is done
here. This is called Deadlock.

System Model:
A system consists of a finite number of resources to be distributed
among a number of competing processes. The resources are partitioned into
several types, each consisting of some number of identical instances. Memory
space, CPU cycles, files, and I/O devices (such as printers and DVD drives)
are examples of resource types.
A process must request a resource before using it and must release the
resource after using it. A process may request as many resources as it
requires to carry out its designated task. Obviously, the number of resources
requested may not exceed the total number of resources available in the
system. In other words, a process cannot request three printers if the system
has only two. Under the normal mode of operation,
1|Page
 A process may utilize a resource in only the following sequence:
 Request:
If the request cannot be granted immediately (for example, if the
resource is being used by another process), then the requesting process
must wait until it can acquire the resource.
 Use :
The process can operate on the resource (for example, if the resource
is a printer, the process can print on the printer).
 Release: The process releases the resource.

Deadlock Characterization:
Deadlock is a situation that occurs in OS when any process enters a waiting state
because another waiting process is holding the demanded resource. Deadlock is a
common problem in multi-processing where several processes share a specific type of
mutually exclusive resource known as a soft lock or software.
Deadlock happens in operating system when two or more processes need some
resource to complete their execution that is held by the other process.
A deadlock occurs if the four Coffman conditions hold true. But these conditions are not
mutually exclusive. They are given as follows:
Example of Deadlock
A real-world example would be traffic, which is going only in one direction.
Here, a bridge is considered a resource.
So, when Deadlock happens, it can be easily resolved if one car backs up
(Preempt resources androllback).
Several cars may have to be backed up if a deadlock situation occurs.
So starvation is possible.

Necessary conditions for deadlocks:

A deadlock situation can arise if the following four conditions hold simultaneously
in a system:
 Mutual exclusion
 Hold and wait
 No preemption
 Circular wait

2|Page
 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. In the diagram
below,there is a single instance of Resource 1 and it is held by Process 1 only.

Hold and Wait:

A process can hold multiple resources and still request more resources from other
processes which are holding them. In the diagram given below, Process 2 holds Resource
2 and Resource 3 and is requestingthe Resource 1 which is held by Process 1.

No Preemption:
A resource cannot be preempted. A process can only release a resource voluntarily
by the process holding it, after that process has completed its task. In the diagram below,

Process 2 cannot preempt Resource 1 from Process 1. It will only be released when
Process 1 relinquishes it voluntarily after its execution is complete.
Circular Wait:
A set {P0, P1, …, Pn} 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 Pn is waiting for a resource that is held by P0. (A
process is waiting for the resource held by the second process, which is waiting for the
resource held by the third process and so on, till the last process is waiting for a
resource held by the first process. This forms a circular chain.)

3|Page
Resource-Allocation Graph:
Deadlocks can be described more precisely in terms of a directed graph
called system resource-allocation graph. This graph consists of a set of vertices
V & a set of edges E.
The set of vertices V is partitioned into two different types of nodes:
P ={P1, P2, . . . Pn}, the set consisting of all the active processes in the
system, and
R = {R1, R2, •••Rm}, the set consisting of all resource types in the
system.
A directed edge from process Pi to resource type Rj is denoted by
Pi ->Rj which signifies that process P i has requested an instance of resource
type Rj, and is currently waiting for that resource. A directed edge Pi—>Rj is
called a Request Edge.
A directed edge from resource type Rj to process Pi is denoted by Rj-> Pi
and signifies that an instance of resource type Rj has been allocated to
process Pi. A directed edge Rj -> Pi is called an Assignment Edge.
Pictorially, we represent each process Pi as a circle and each resource
type Rj as a rectangle. Since resource type Rj may have more than one

instance, we represent each such instance as a dot within the rectangle.

States of above RAG:
Process P1is holding an instance of resource type R2 and is waiting for
an instance of resource type R1. Process P2 is holding an instance of R1and
an instance of R2 and is waiting for an instance of R3. ProcessP3 is holding
an instance of R3.
When process Pi, requests an instance of resource type Rj, a request
edge is inserted in the resource-allocation graph. When this request can be
fulfilled, the request edge is instantaneously transformed to an assignment
edge. When the process no longer needs access to the resource, it releases
the resource; as a result, the assignment edge is deleted.
Given the definition of a resource-allocation graph, it can be shown
that, if the graph contains no cycles, then no process in the system is
deadlocked. If the graph does contain a cycle, then a deadlock may exist.

4|Page
 If each resource type has several instances, then a cycle does not
necessarily imply that a deadlock has occurred. In this case, a cycle in the
graph is a necessary but not a sufficient condition for the existence of
deadlock.

Processes P1, P2, and P3 are deadlocked. Process P2 is waiting for the
resource R3, which is held by process P3. Process P3 is waiting for either
process P1or process P2to release resource R2. In addition, process P1 is
waiting for process P2 to release resource R1.

Consider the resource-allocation graph as shown in above figure a cycle is

formed but there is no deadlock. From the above resource allocation graph
Process P4 may release its instance of resource type R2 That resource can then
be allocated to P3, breaking the cycle. So, we can say that if a resource-
allocation graph does not have a cycle, then the system is not in a deadlocked
state. If there is a cycle, then the system may or may not be in a deadlocked
state.

Methods for Handling Deadlocks:

Generally speaking, we can deal with the deadlock problem in one of
three ways:
We can use a protocol to prevent or avoid deadlocks, ensuring that the
system will never enter a deadlock state.
We can allow the system to enter a deadlock state, detect it, and recover.
We can ignore the problem altogether and pretend that deadlocks never
occur in the system.
The third solution is the one used by most operating systems, including
UNIX and Windows; it is then up to the application developer to write
programs that handle deadlocks. To ensure that deadlocks never occur, the
system can use either a deadlock- prevention or a deadlock-avoidance
scheme.
5|Page
Deadlock Prevention:
For a deadlock to occur, each of the four necessary conditions must
hold. By ensuring that at least one of these conditions cannot hold, we can
prevent the occurrence of a deadlock.
Mutual exclusion
Hold and wait
No pre-emption
Circular wait
Mutual exclusion:
The mutual-exclusion condition must hold for non-sharable
resources. For example, a printer cannot be simultaneously shared by
several processes. Sharable resources, in contrast, do not require mutually
exclusive access and thus cannot be involved in a deadlock. Read-only files
are a good example of a sharable resource. If several processes attempt to
open a read-only file at the same time, they can be granted simultaneous
access to the file.
A process never needs to wait for a sharable resource. In general,
however, we cannot prevent deadlocks by denying the mutual-exclusion
condition, because some resources are intrinsically non-sharable.
Hold and Wait:
To ensure that the hold-and-wait condition never occurs in the system,
we must guarantee that, whenever a process requests a resource, it does not
hold any other resources. One protocol that can be used requires each
process to request and be allocated all its resources before it begins
execution.
An alternative protocol allows a process to request resources only when
it has none. A process may request some resources and use them. Before it
can request any additional resources, however, it must release all the
resources that it is currently allocated.
Ex:
we consider a process that copies data from a DVD drive to a file on disk,
sorts the file, and then prints the results to a printer.
If all resources must be requested at the beginning of the process, then the
process must initially request the DVD drive, disk file, and printer. It will hold
the printer for its entire execution, even though it needs the printer only at the
end.
The second method allows the process to request initially only the DVD
drive and disk file. It copies from the DVD drive to the disk and then releases
both the DVD drive and the disk file. The process must then again request
the disk file and the printer. After copying the disk file to the printer, it
releases these two resources and terminates. These protocols have two main
disadvantages. First, resource utilization may be low and second starvation
is possible.

6|Page
No Preemption:
The third necessary condition for deadlocks is that there be no pre-emption
of resources that have already been allocated. To ensure that this condition
does not hold, we can use the following protocol.
If a process is holding some resources and requests another resource
that cannot be immediately allocated to it (that is, the process must wait),
then all resources currently being held are pre-empted. In other words, these
resources are implicitly released. The pre-empted resources are added to the
list of resources for which the process is waiting. The process will be
restarted only when it can regain its old resources, as well as the new ones
that it is requesting.
If a process requests some resources, we first check whether they are
available. If they are, we allocate them. If they are not, we check whether
they are allocated to some other process that is waiting for additional resources.
If so, we pre-empt the desired resources from the waiting process and allocate
them to the requesting process.
If the resources are neither available nor held by a waiting process, the
requesting process must wait. While it is waiting, some of its resources may
be pre-empted, but only if another process requests them. A process can be
restarted only when it is allocated the new resources it is requesting and
recovers any resources that were pre-empted while itwas waiting.
Circular Wait:
The fourth and final condition for deadlocks is the circular-wait
condition. One way to ensure that this condition 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.
Let R = {R1, R2, ..., Rm} be the set of resource types. We assign to each
resource type a unique integer number, which, allows us to compare two
resources and to determine whether one precedes another in our ordering.
Ex:
If the set of resource types R includes tape drives, disk drives, and
printers, then thefunction F might be defined as follows:
F(tape drive) = 1
F(disk drive) = 5
F (printer) = 12
The process can request instances of resource type R;
if and only if F (Rj)>F (Ri). Alternatively, we can require that, whenever a
process requests an instance of resourcetype R it has released any resources R
such that If these two protocols are used, then the circular-wait condition
cannot hold.

7|Page
Deadlock Avoidance:
Method for avoiding deadlocks is to require additional information about
how resources are to be requested.
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. More formally, a
system is in a safe state only if there exists a safe sequence. If no such
sequence exists, then the systemstate is said to be unsafe.

A safe state is not a deadlocked state. Conversely, a deadlocked state is

an unsafe state. Not all unsafe states are deadlocks, however an unsafe state
may lead to a deadlock.
Ex: With single instance of a resource type
Suppose there are four processes in execution with 12 instances of a
resource in a system.
With reference to current allocation, is system safe? If so what is the safe
sequence?
Process Maximum Current Need
Allocation
P1 8 3 5
P2 9 4 5
P3 5 2 3
P4 3 1 2
Total =10
Total no. of resources = 12
Total no. of resources used = 10
Total no. of resources left = 12-10=2
Now 2 units of resources left
If 2 units given to process P1 => 3+2=5 X incomplete
If 2 units given to process P2 => 4+2=6 X incomplete
If 2 units given to process P3 => 2+2=4 X incomplete
If 2 units given to process P4 => 1+2=3 √ complete
Now 3 units of resources were released.
If 3 units given to process P1 => 3+3=6 X incomplete
If 3 units given to process P2 => 4+3=7 X incomplete
If 3 units given to process P3 => 2+3=5 √ complete
Now 5 units of resources were released.
If 5 units given to process P1 => 3+5=8 √ complete
Now 8 units of resources were released.
If 8 units given to process P2 => 4+5=9=>9+3=12 √ complete
So, the safe sequence is <P4, P3, P1, P2>

8|Page
Resource-Allocation-Graph Algorithm for Single Instance:
In addition to the request and assignment edges, we have a new type of
edge, called a claim edge. A claim edge Pi —>Rj indicates that process Pi may
request resource Rj, at some time in the future. This edge resembles a request
edge in direction but is represented in the graph by a dashed line as shown
below.

When process Pi requests resource Rj, the claim edge Pi —>Rj is

converted to a request edge. Similarly, when a resource Rj is released by Pi,
the assignment edge Rj->Pi is reconverted to a claim edge P i—>Rj. We note
that the resources must be claimed a priori in the system. That is, before
process Pi starts executing, all its claim edges must already appear in the
resource-allocation graph.
If no cycle exists, then the allocation of the resource will leave the
system in a safe state. If a cycle is found, then the allocation will put the
system in an unsafe state. Therefore, process P will have to wait for its
requests to be satisfied.

A cycle indicates that the system is in an unsafe state. If P1

requests R2, and P2requests R1, then a deadlock will occur.
Banker's Algorithm:
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
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.
Let n be the number of processes in the system and m be the number of
resource types. We need the following data structures:

9|Page
 Safety Algorithm:

We can now present algorithm for finding out whether or not system is
in safe state. This algorithm can be described, as follows:

Resource-Request Algorithm:
We now describe the algorithm which determines if requests can be safely
granted.

10 | P a g e
Ex:
Consider a system that contains five processes P1, P2, P3, P4, P5 and the three
resource types A, B and C. Following are the resources types:
A has 10, B has 5 and the resource type C has 7 instances.

Process Allocation Max Available

A B C A B C A B C

P1 0 1 0 7 5 3 3 3 2

P2 2 0 0 3 2 2

P3 3 0 2 9 0 2

P4 2 1 1 2 2 2

P5 0 0 2 4 3 3
1. Determine if the system is safe or not?
2. What will happen if process P1 requests one additional instance of resource type A
and two instances of resource type C?
Need [i] = Max [i] - Allocation [i]
Need for P1: (7, 5, 3) - (0, 1, 0) = 7, 4, 3
Need for P2: (3, 2, 2) - (2, 0, 0) = 1, 2, 2
Need for P3: (9, 0, 2) - (3, 0, 2) = 6, 0, 0
Need for P4: (2, 2, 2) - (2, 1, 1) = 0, 1, 1
Need for P5: (4, 3, 3) - (0, 0, 2) = 4, 3, 1

Process Need
A B C

P1 7 4 3

P2 1 2 2

P3 6 0 0

P4 0 1 1

P5 4 3 1
Hence, we created the context of need matrix.
Apply the Banker's Algorithm:
Available Resources of A, B and C are 3, 3, and 2.
Now we check if each type of resource request is available for each process.
Step 1: For Process P1:
Work=Available
Work=3, 3, 2
Need <= Work
7, 4, 3 <= 3, 3, 2 condition is false.

11 | P a g e
Now, examine another process, P2.
Step 2: For Process P2:
Work = 3, 3, 2
Need <= Work
1, 2, 2 <= 3, 3, 2 condition true
Work = Work + Allocation
(3, 3, 2) + (2, 0, 0) => 5, 3, 2
Now, examine another process P3.
Step 3: For Process P3:
Work = 5, 3, 2
Need <= Work
6, 0, 0 < = 5, 3, 2 condition is false.
Now, examine another process, P4.
Step 4: For Process P4:
Work = 5, 3, 2
Need <= Work
0, 1, 1 <= 5, 3, 2 condition is true
Work = Work + Allocation
5, 3, 2 + 2, 1, 1 => 7, 4, 3
Now, examine another process P5.
Step 5: For Process P5:
Work = 7, 4, 3
Need <= Work
4, 3, 1 <= 7, 4, 3 condition is true
Work = Work + Allocation
7, 4, 3 + 0, 0, 2 => 7, 4, 5
Again, examine each type of resource request for processes P1 and P3.
Now, examine another process P2.
Step 6: For Process P1:
Work = 7, 4, 5
Need <= Work
7, 4, 3 <= 7, 4, 5 condition is true
Work = Work + Allocation
7, 4, 5 + 0, 1, 0 => 7, 5, 5
Now, examine another process P2.
Step 7: For Process P3:
Work = 7, 5, 5
Need <= Work
6, 0, 0 <= 7, 5, 5 condition is true
Work = Work + Allocation
7, 5, 5 + 3, 0, 2 => 10, 5, 7
Hence, we execute the banker's algorithm to find the safe state and the safe
sequence like < P2, P4, P5, P1 and P3 >.

What will happen if process P1 requests one additional instance of resource type A
and two instances of resource type C?

12 | P a g e
 We must determine whether this new system state is safe. To do so, we again
execute Safety algorithm on the above data structures.
(Given in notes)

13 | P a g e
 Deadlock Detection:
If a system does not employ either a deadlock-prevention or a deadlock
avoidance algorithm, then a deadlock situation may occur.
In this environment, the system must provide:
An algorithm that examines state of the system to determine whether a
deadlock has occurred
An algorithm to recover from the deadlock
we elaborate on these two requirements as they pertain to systems with only a
single instance of each resource type, as well as to systems with several
instances of each resource type. At this point, however, we note that a detection- and-
recovery scheme requires overhead that includes not only the run-time costs of
maintaining the necessary information and executing the detection algorithm
but also the potential losses inherentin recovering from a deadlock.
1. 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. More precisely, an
edge from in a wait-for graph implies that process P1 is waiting for process
P2 to release a resource that P needs.
An edge exists in a wait-for graph if and only if the corresponding resource
allocation graph contains two edges and for some resource.
For example, consider a resource-allocation graph and the corresponding
wait-for graphas shown below:

As before, a deadlock exists in the system if and only if the wait-for

graph contains a cycle. To detect deadlocks, the system needs to maintain the
wait-for graph and periodically invoke an algorithm that searches for a cycle
in the graph.
14 | P a g e
 2 : Several Instances of a Resource Type:
The wait-for graph scheme is not applicable to a resource-allocation
system with multiple instances of each resource type. We turn now to a
deadlock detection algorithm that is applicable to such a system. The
algorithm employs several time-varying data structures that are similar to

To simplify notation, we treat the rows in the matrices Allocation and

Request as vectors. The detection algorithm described here simply investigates
every possible allocation sequence for the processes that remain to be completed.

A = 7, B = 2, C = 6

Available Resources of A, B and C are 0, 0, 0.

Now we check if each type of resource request is available for each process.
Step 1: For Process P0:
Work=Available
Work=0, 0, 0
Request <= Work
0, 0, 0 <= 0, 0, 0 condition is true.

15 | P a g e
 Work = Work + Allocation
0, 0, 0 + 0, 1, 0 => 0, 1, 0
Now, examine another process,
P1. Step 2: For Process P1:
Work=0, 1, 0
Request <= Work
2, 0, 2 <= 0, 0, 0 condition is false.
Now, examine another process,
P2. Step 3: For Process P2:
Work=0, 1, 0
Request <= Work
0, 0, 0 <= 0, 1, 0 condition is true.
Work = Work + Allocation
0, 1, 0 + 3, 0, 3 => 3, 1, 3
Now, examine another process,
P3. Step 4: For Process P3:
Work=3, 1, 3
Request <= Work
1, 0, 0 <= 3, 1, 3 condition is true.
Work = Work + Allocation
3, 1, 3 + 2, 1, 1 => 5, 2, 4
Now, examine another process,
P4. Step 5: For Process P4:
Work=5, 2, 4
Request <= Work
0, 0, 2 <= 5, 2, 4 condition is true.
Work = Work + Allocation
5, 2, 4 + 0, 0, 2 => 5, 2, 6
Now, examine another process,
P1. Step 5: For Process P1:
Work=5, 2, 6
Request <= Work
2, 0, 2 <= 5, 2, 6 condition is true.
Work = Work + Allocation
5, 2, 6 + 2, 0, 0 => 7, 2, 6
Since Finish is a vector of all true it means there is no deadlock in the above example
and the sequence is < P0, P2, P3, P4, P1 >.
3 : Detection-Algorithm Usage
When should we invoke the detection algorithm? The answer depends on
two factors:
 How often is a deadlock likely to occur?
 How many processes will be affected by deadlock when it happens?
If deadlocks occur frequently, then the detection algorithm should be
invoked frequently. Resources allocated to deadlocked processes will be idle
until the deadlock can be broken. In addition, the number of processes
involved in the deadlock cycle may grow.

16 | P a g e
 Deadlocks occur only when some process makes a request that
cannot be granted immediately. This request may be the final request that
completes a chain of waiting processes. In the extreme, we can invoke the
deadlock detection algorithm every time a request for allocation cannot be
granted immediately. In this case, we can identify not only the deadlocked
set of processes but also the specific process that "caused" the deadlock.
If there are many different resource types, one request may create
many cycles in the resource graph, each cycle completed by the most recent
request and "caused" by the one identifiable
process.
Of course, if the deadlock-detection algorithm is invoked for every
resource request, this will incur a considerable overhead in computation time.
A less expensive alternative is simply to invoke the algorithm at less frequent
intervals

Recovery From Deadlock:

When a detection algorithm determines that a deadlock exists, several
alternatives are available. One possibility is to inform the operator that a
deadlock has occurred and to let the operator deal with the deadlock
manually. Another possibility is to let the system recover from the deadlock
automatically.
There are two options for breaking a deadlock. One is simply to abort one
or more processes to break the circular wait. The other is to pre-empt some
resources from oneor more of the deadlocked processes.
1. Process Termination:
To eliminate deadlocks by aborting a process, we use one of two methods.
In both methods, the system reclaims all resources allocated to the terminated
processes.
 Abort all deadlocked Processes:
This method clearly will break the deadlock cycle, but at great
expense; the deadlocked processes may have computed for a long time,
and the results of these partial computations must be discarded and
probably will have to be recomputed later.
 Abort one process at a time until the deadlock cycle is eliminated :
This method incurs considerable overhead, since, after each
process is aborted, a deadlock-detection algorithm must be invoked to
determine whether any processes are still deadlocked.
 Aborting a process may not be easy:
If the process was in the midst of updating a file, terminating it
will leave that file in an incorrect state. Similarly, if the process was in
the midst of printing data on a printer, the system must reset the
printer to a correct state before printing the next job.
If the partial termination method is used, then we must determine which
deadlocked process (or processes) should be terminated. This determination
is a policy decision, similar to CPU-scheduling decisions.

17 | P a g e
 The question is basically an economic one; we should abort those
processes whose termination will incur the minimum cost. Unfortunately, the
term minimum cost is not a precise one.
Many factors may affect which process is chosen, including:
 What the priority of the process is
 How long the process has computed and how much longer the process
willcompute before completing its designated task
 How many and what type of resources the process has used (for
example, whetherthe resources are simple to pre-empt)
 How many more resources the process needs in order to complete
 How many processes will need to be terminated
 Whether the process is interactive or batch
2: Resource Pre-emption:
To eliminate deadlocks using resource pre-emption, we successively pre-
empt some resources from processes and give these resources to other
processes until the deadlock cycle is broken.
If pre-emption is required to deal with deadlocks, then three issues need to
be addressed:
 Selecting a Victim :
Which resources and which processes are to be pre-empted? As in
process termination, we must determine the order of pre-emption to
minimize cost. Cost factors may include such parameters as the
number of resources a deadlocked process is holding and the amount
of time the process has thus far consumed during its execution.
 Rollback :
If we pre-empt a resource from a process, what should be done
with that process? Clearly, it cannot continue with its normal
execution; it is missing some needed resource. We must roll back the
process to some safe state and restart it from that state.
Since, in general, it is difficult to determine what a safe state is, the
simplest solution is a total rollback: Abort the process and then restart it.
Although it is more effective to roll back the process only as far as necessary
to break the deadlock, this method requires the system to keep more
information about the state of all running processes.
 Starvation :
How do we ensure that starvation will not occur? That is, how
can we guarantee that resources will not always be pre-empted from the
same process?
In a system where victim selection is based primarily on cost factors, it
may happen that the same process is always picked as a victim. As a
result, this process never completes its designated task, a starvation situation
that must be dealt with in any practical system. Clearly, we must ensure that a
process can be picked as a victim only a (small) finite number of times. The most
common solution is to include the number ofrollbacks in the cost factor.

18 | P a g e