Subject: Operating System

Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

PROCESS SYNCRONIZATION
A situation where several processes access and manipulate the same
data concurrently and the outcome of the execution depends on the
particular order in which the access takes place, is called race
condition.
To guard against the race condition above we need to ensure that
only one process at a time can be manipulating the variable counter.
Situation like this occur frequently in OS as different parts of the
system manipulate resources. So, synchronization and coordination
of processes is required.

The critical Section Problem

When one process is executing in its critical section, no other process
is to be allowed to execute in its critical section, i.e. no two processes
are executing in their critical section at a time.
The CSP is designed a protocol that the processes can use to
cooperate. Each process must request permission to enter its critical
section. The section of code implementing this request is the entry
section. The critical section may be followed by an exit section. The
remaining code is the remainder sections.
do{
entry section

critical section
exit section
remainder section
} while (TRUE);

Contact: 7008443534, 9090042626 1|Page

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

A solution to the critical section problem must satisfy the following

three requirements.
Mutual Exclusion – If process P1 is executing in its critical section,
then no other process can be executed in their critical sections.
Progress – If no process is executing in its critical section and some
processes wish to enter their critical sections, then only those
processes that are not executing in their remainder sections can
participate in deciding which will enter its critical section next, and
this selection cannot be postponed indefinitely.
Bounded Waiting – There exists a bound, or limit, on the number of
that other processes are allowed to enter their critical sections after
a process has made request to enter its critical section and before
that request is granted.

Peterson's solution for critical section problem

Peterson's solution is restricted to two processes that alternate
execution between their critical sections and remainder sections.
The processes are numbered Po and P1. For convenience, when
presenting Pi, we use Pj to denote the other process;
that is, j equals 1 - i.

Peterson's solution requires the two processes to share two data

items:
int turn;
boolean flag[2];

The variable turn indicates whose turn it is to enter its critical

section. That is, if turn == i, then process Pi is allowed to execute in
its critical section. The flag array is used to indicate if a process is
ready to enter its critical section.

Contact: 7008443534, 9090042626 2|Page

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

do {
flag [i] = TRUE;
turn= j;
while (flag[j] && turn j);

critical section
flag [i] = FALSE;

remainder section
} while (TRUE);
To enter the critical section, process Pi first sets flag [i] to be true and
then sets turn to the value j, thereby asserting that if the other
process wishes to enter the critical section, it can do so. If both
processes try to enter at the same time, turn will be set to both i and
j at roughly the same time. Only one of these assignments will last;
the other will occur but will be overwritten immediately.
The eventual value of turn determines which of the two processes is
allowed to enter its critical section first.

Synchronization Hardware
The critical-section problem could be solved simply in a uniprocessor
environment if we could prevent interrupts from occurring while a
shared variable was being modified.

In this manner, we could be sure that the current sequence of

instructions would be allowed to execute in order without
preemption.

Contact: 7008443534, 9090042626 3|Page

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

No other instructions would be run, so no unexpected modifications

could be made to the shared variable. This is often the approach
taken by nonpreemptive kernels.

Many modern computer systems therefore provide special hardware

instructions that allow us either to test and modify the content of a
word or to swap the contents of two words atomically – that is, as
one uninterruptible unit. We can use these special instructions to
solve the critical-section problem in a relatively simple manner.

do {
while (TestAndSet(&lock))
; // do nothing
// critical section
lock = FALSE;
// remainder section
} while (TRUE);

[Mutual-exclusion implementation with TestAndSet ()]

do {
key = TRUE;
while (key == TRUE)
Swap(&lock, &key);
// critical section
lock = FALSE;
// remainder section
} while (TRUE);

[Mutual-exclusion implementation with the Swap() instruction.]

Semaphores
• It is a mechanism that can be used to provide synchronization of tasks.
• It is a low-level synchronization mechanism.
• Semaphore will always hold a non-negative integer value.

Contact: 7008443534, 9090042626 4|Page

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

• Semaphore can be implemented using test operations and interrupts,

which should be executed using file descriptors.

Types of Semaphores
The two common kinds of semaphores are

• Counting semaphores
• Binary semaphores.

Counting Semaphores
This type of Semaphore uses a count that helps task to be acquired or released
numerous times. If the initial count = 0, the counting semaphore should be
created in the unavailable state.

However, If the count is > 0, the semaphore is created in the available state, and
the number of tokens it has equals to its count.

Binary Semaphores
The binary semaphores are quite similar to counting semaphores, but their
value is restricted to 0 and 1. In this type of semaphore, the wait operation
works only if semaphore = 1, and the signal operation succeeds when
semaphore= 0. It is easy to implement than counting semaphores.

Contact: 7008443534, 9090042626 5|Page

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

Example of Semaphore
The below-given program is a step by step implementation, which involves
usage and declaration of semaphore.

Shared var mutex: semaphore = 1;

Process i
begin
.
.
P(mutex);
execute CS;
V(mutex);
.
.
End;

Counting Semaphore vs. Binary Semaphore

Counting Semaphore Binary Semaphore

No mutual exclusion Mutual exclusion

Any integer value Value only 0 and 1

More than one slot Only one slot

Provide a set of Processes It has a mutual exclusion mechanism.

Contact: 7008443534, 9090042626 6|Page

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

Advantages of Semaphores
• It allows more than one thread to access the critical section
• Semaphores are machine-independent.
• Semaphores are implemented in the machine-independent code of the
microkernel.
• They do not allow multiple processes to enter the critical section.
• As there is busy waiting in semaphore, there is never a wastage of process
time and resources.
• They are machine-independent, which should be run in the machine-
independent code of the microkernel.
• They allow flexible management of resources.

Disadvantage of semaphores
• One of the biggest limitations of a semaphore is priority inversion.
• The operating system has to keep track of all calls to wait and signal
semaphore.
• Their use is never enforced, but it is by convention only.
• In order to avoid deadlocks in semaphore, the Wait and Signal operations
require to be executed in the correct order.
• Semaphore programming is a complicated, so there are chances of not
achieving mutual exclusion.
• It is also not a practical method for large scale use as their use leads to
loss of modularity.
• Semaphore is more prone to programmer error.
• It may cause deadlock or violation of mutual exclusion due to
programmer error.

Classical problems of Synchronization

1) The Bounded buffer problem
2) The Readers-writers problem
3) The Dining- Philosophers problem

Contact: 7008443534, 9090042626 7|Page

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

The Bounded buffer problem

It is also known as producer-consumer problem.
It is used to illustrate the power of synchronization primitives. We assume that
the pull consists of ‘n’ buffers each capable of holding one item.
The mutex semaphores provide the mutual exclusion for accesses to the buffer
pool and is initialized to the value 1. The empty and full semaphores count the
number of empty and full buffers.
The code for the producer process is shown in Figure A; the code for the
consumer process is shown in Figure B. Note the symmetry between the
producer and the consumer. We can interpret this code as the producer
producing full buffers for the consumer or as the consumer producing empty
buffers for the producer.
The semaphores empty is initialized to the value n. The semaphore full is
initialized to the value 0.
do { do {
wait (full); ....
wait (mutex) ; // produce an item in nextp
.... ....
// remove an item from buffer to nextc wait(empty);
.... wait(mutex);
signal(mutex); ....
signal(empty); // add nextp to buffer
....
....
// consume the item in nextc
signal(mutex);
....
} while (TRUE); signal(full);
} while (TRUE);

[Fig.(B) The structure of the consumer process.] [Figure (A) The structure of the producer process.]

The Readers – Writers Problem

Suppose that a database is to be shared among several concurrent processes.
Some of these processes may want only to read the database, whereas others
may want to update (that is, to read and write) the database.

We distinguish between these two types of processes by referring to the

former as readers and to the latter as writers.

Contact: 7008443534, 9090042626 8|Page

 Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

If two readers access the shared data simultaneously, no adverse effects will
result. However, if a writer and some other process (either a reader or a
writer) access the database simultaneously, chaos may ensue.

To ensure that these difficulties do not arise, we require that the writers
have exclusive access to the shared database while writing to the database.
This synchronization problem is referred to as the readers-writers problem.

do { do {
wait(wrt); wait (mutex);
.... readcount++;
// writing is performed
if (readcount == 1)
....
wait (wrt);
signal(wrt);
signal(mutex);
} while (TRUE);
....
// reading is performed
....
wait(mutex);
readcount--;
if (readcount == 0)
signal(wrt);
signal(mutex);
} while (TRUE);

[ The structure of a writer process.] [The structure of a reader process.]

The Dining Philosophers Problem

Contact: 7008443534, 9090042626 9|Page

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

Consider five philosophers who spend their lives thinking and eating. The
philosophers share a circular table surrounded by five chairs, each belonging to
one philosopher. In the center of the table is a bowl of rice, and the table is laid
with five single chopsticks. When a philosopher thinks, she does not interact
with her colleagues. From time to time, a philosopher gets hungry and tries to
pick up the two chopsticks that are closest to her (the chopsticks that are
between her left and right neighbours).

A philosopher may pick up only one chopstick at a time. Obviously, she cannot
pick up a chopstick that is already in the hand of a neighbour.

When a hungry philosopher has both her chopsticks at the same time, she
eats without releasing her chopsticks. When she is finished eating, she puts
down both of her chopsticks and starts thinking again.

This concurrency problem is called dining philosopher problem

.
do {
wait(chopstick[i]);
wait(chopstick[(i+1) % 5]);
....
// eat
....
signal(chopstick[i]);
signal(chopstick[(i+1) % 5]);
....
// think
....
} while (TRUE);

[The structure of philosopher i]

Contact: 7008443534, 9090042626 10 | P a g e

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

Monitors
Semaphores provide a convenient and effective mechanism for process
synchronization, using them incorrectly can result in timing errors that are
difficult to detect, since these errors happen only if some particular execution
sequences take place and these sequences do not always occur.

A abstract data type- or ADT- encapsulates private data with public methods
to operate on that data. A monitor type is an ADT which presents a set of
programmer-defined operations that are provided mutual exclusion within
the monitor.

The monitor type also contains the declaration of variables whose values
define the state of an instance of that type, along with the bodies of
procedures or functions that operate on those variables.

monitor monitor name

{
II shared variable declarations
procedure P1 ( . . . ) {
…..
}
procedure P2 ( . . . ) {
….
}
.
.
.
procedure Pn ( . . . ) {
…..
}
initialization code ( . . . ) {
…..
}
}
[Syntax of a monitor.]

The representation of a monitor type cannot be used directly by the various

processes. Thus, a procedure defined within a monitor can access only those
variables declared locally within the monitor and its formal parameters.
Contact: 7008443534, 9090042626 11 | P a g e
Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

Similarly, the local variables of a monitor can be accessed by only the local
procedures.

Dining-Philosophers Solution Using Monitors

This solution imposes the restriction that a philosopher may pick up her
chopsticks only if both of them are available. To code this solution, we need to
distinguish among three states in which we may find a philosopher

enum{THINKING, HUNGRY, EATING}state[5];

Philosopher i can set the variable state [i] = EATING only if her two
neighbors are not eating: (state [ (i +4) % 5] ! = EATING) and (state [ (i +1)
% 5] != EATING).

We also need to declare

condition self[5];

in which philosopher i can delay herself when she is hungry but is unable to
obtain the chopsticks she needs.

The distribution of the chopsticks is controlled by the monitor

DiningPhilosophers. Each philosopher, before starting to eat, must invoke the
operation pickup().

This act may result in the suspension of the philosopher process. After the
successful completion of the operation, the philosopher may eat. Following
this, the philosopher invokes the putdown() operation.
monitor dp
{

enum {THINKING, HUNGRY, EATING} state[5];

condition self[5];

void pickup(int i) {
state[i] =HUNGRY;
test(i);
if (state [i] ! = EATING)
self [i] . wait() ;
}

void putdown(int i) {

Contact: 7008443534, 9090042626 12 | P a g e

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

state[i] =THINKING;
test((i + 4) % 5);
test((i + 1) % 5);
}
void test(int i) {
if ((state[(i + 4) % 5] !=EATING) &&
(state[i] ==HUNGRY) &&
(state[(i + 1) % 5] !=EATING)) {
state[i] =EATING;
self[i] .signal();
}
}
initialization_code() {
for (int i = 0; i < 5; i++)
state[i] =THINKING;
}
}

[A monitor solution to the dining-philosopher problem]

Bounded Buffer Solution Using Semaphore

To solve this problem, we need two counting semaphores – Full and Empty.
“Full” keeps track of number of items in the buffer at any given time and
“Empty” keeps track of number of unoccupied slots.
Initialization of semaphores –
mutex = 1
Full = 0 // Initially, all slots are empty. Thus full slots are 0
Empty = n // All slots are empty initially
Solution for Producer –
do{
//produce an item
wait(empty);
wait(mutex);

//place in buffer
signal(mutex);
signal(full);
}while(true)

Contact: 7008443534, 9090042626 13 | P a g e

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

When producer produces an item then the value of “empty” is reduced by 1

because one slot will be filled now. The value of mutex is also reduced to
prevent consumer to access the buffer. Now, the producer has placed the item
and thus the value of “full” is increased by 1. The value of mutex is also
increased by 1 beacuse the task of producer has been completed and
consumer can access the buffer.
Solution for Consumer –
do{
wait(full);
wait(mutex);

// remove item from buffer

signal(mutex);
signal(empty);

// consumes item
}while(true)
As the consumer is removing an item from buffer, therefore the value of “full”
is reduced by 1 and the value is mutex is also reduced so that the producer
cannot access the buffer at this moment. Now, the consumer has consumed
the item, thus increasing the value of “empty” by 1. The value of mutex is also
increased so that producer can access the buffer now.

Implementing a Monitor Using Semaphores

For each monitor, a semaphore mutex (initialized to 1) is provided.
A process must execute wait (mutex) before entering the monitor and must
execute signal (mutex) after leaving the monitor.
Since a signaling process must wait until the resumed process either leaves
or waits, an additional semaphore, next, is introduced, initialized to 0. The
signaling processes can use next to suspend themselves.

An integer variable next_count is also provided to count the number of

processes suspended on next. Thus, each external procedure F is replaced by

Contact: 7008443534, 9090042626 14 | P a g e

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

wait(mutex);
...
body of F
...
if (next_count > 0)
signal(next);
else
signal(mutex);

Mutual exclusion within a monitor is ensured.

We can now describe how condition variables are implemented as well.

For each condition x, we introduce a semaphore x_sem and an integer
variable x_count, both initialized to 0. The operation x. wait() can now be
implemented as

x_count++;
if (next_count > 0)
signal(next);
else
signal(mutex);
wait (x_sem) ;
x_count--;

The operation x. signal() can be implemented as

if (x_count > 0) {
next_count++;
signal(x_sem);
wait(next);
next_count--;
}

Atomic Transactions
The mutual exclusion of critical sections ensures that the critical sections are
executed atomically -that is, as one uninterruptible unit. If two critical sections
are instead executed concurrently, the result is equivalent to their sequential
execution in some unknown order.

Contact: 7008443534, 9090042626 15 | P a g e

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

The mutual exclusion of critical sections ensures that the critical sections are
executed atomically -that is, as one uninterruptible unit. If two critical sections
are instead executed concurrently, the result is equivalent to their sequential
execution in some unknown order.
Volatile storage: Information residing in volatile storage does not usually
survive system crashes. Examples of such storage are main and cache
memory.
Nonvolatile storage: Information residing in nonvolatile storage usually
survives system crashes. Examples of media for such storage are disks and
magnetic tapes.
Stable storage: Information residing in stable storage is never lost (never
should be taken with a grain of salt, since theoretically such absolutes
cannot be guaranteed).

Deadlocks
In a multiprogramming environment, several processes may compete for a
finite number of resources. A process requests resources; 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.

System Models
A system model or structure consists of a fixed number of resources to
be circulated among some opposing processes. The resources are then
partitioned into numerous types, each consisting of some specific
quantity of identical instances. Memory space, CPU cycles, directories
and files, I/O devices like keyboards, printers and CD-DVD drives are
prime examples of resource types. When a system has 2 CPUs, then
the resource type CPU got two instances.

Under the standard mode of operation, any process may use a resource
in only the below-mentioned sequence:

Contact: 7008443534, 9090042626 16 | P a g e

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

1. Request: When the request can't be approved immediately

(where the case may be when another process is utilizing the
resource), then the requesting job must remain waited until it can
obtain the resource.
2. Use: The process can run on the resource (like when the
resource is a printer, its job/process is to print on the printer).

• Release: The process releases the resource (like, terminating or

exiting any specific process).

Deadlock Characterization
A deadlock situation can arise if the following four condition hold
simultaneously in a system:
1) Mutual exclusion. At least one resource must be held in a nonsharable
mode; that is, only one process at a time can use the resources.
2) Hold and wait. A process must be holding at least one resource and
waiting to acquire additional resources that are currently being held by
other processes.
3) No preemption. Resources cannot be preempted; that is, a resource can
be released only voluntarily by the process holding it, after that process
has completed its task.

4) Circular wait. A set {P0, P1, ... , Pn } of waiting processes must exist such
that P0 is waiting for a resource held by P1, P1 is waiting for a resource
held by P2, ... , Pn-1 is waiting for a resource held by Pn, and Pn is waiting
for a resource held by Po.

Resource Allocation Graph

Deadlocks can be described more precisely in terms of a directed graph called
A system resource allocation graph. This graph consists of a set of vertices V
and 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.

Contact: 7008443534, 9090042626 17 | P a g e

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

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 P1 or
process P2 to release resource R2. In addition, process P1 is waiting for process
P2 to release resource R1.

Methods for handling Deadlock

We can deal with the deadlock problem in one of three ways:

1) We can use a protocol to prevent or avoid deadlocks, ensuring that the

system will never enter a deadlocked state.
2) We can allow the system to enter a deadlocked state, detect it, and
recover.
3) 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.

Deadlock Prevention
By ensuring that at least one of these conditions cannot hold, we can prevent
the occurrence of a deadlock.

Mutual Exclusion
The mutual-exclusion condition must hold for nonsharable 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.

Contact: 7008443534, 9090042626 18 | P a g e

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

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.
No Preemption
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 the process is currently holding are preempted. In other words,
these resources are implicitly released.
Circular Wait
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.

Deadlock Avoidance
By restraining one of the necessary conditions for deadlock cannot occur and,
hence, that deadlocks cannot hold.
An alternative 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.

A sequence of processes <P1, P2, ..., Pn> is a safe sequence for the current
allocation state if, for each Pi, the resource requests that Pi can still make can
be satisfied by the currently available resources plus the resources held by all
Pj, with j < i.

Contact: 7008443534, 9090042626 19 | P a g e

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

Resource-Allocation-Graph Algorithm

Suppose that process Pi requests resource Rj. The request can be

granted only if converting the request edge Pi -> Rj to an assignment edge
Rj -> Pi does not result in the formation of a cycle in the resource-allocation
graph. We check for safety by using a cycle-detection algorithm.

An algorithm for detecting a cycle in this graph requires an order of n2

operations, where n is the number of processes in the system.

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.

Banker's Algorithm

The name Banker's Algorithm was chosen because the algorithm could be used in
a banking system to ensure that the bank never allocated its available cash in
such a way that it could no longer satisfy the needs of all its customers.

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.

Contact: 7008443534, 9090042626 20 | P a g e

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

For example, there are X number of account holders of a specific bank, and
the total amount of money of their accounts is G.

When the bank processes a car loan, the software system subtracts the
amount of loan granted for purchasing a car from the total money ( G+ Fixed
deposit + Monthly Income Scheme + Gold, etc.) that the bank has.

It also checks that the difference is more than or not G. It only processes the
car loan when the bank has sufficient money even if all account holders
withdraw the money G simultaneously.

Deadlock Detection
If a system does not employ either a deadlock prevention or deadlock avoidance
algorithm then a deadlock situation may occur.
In this case-
• Apply an algorithm to examine state of system to determine whether deadlock
has occurred or not.
• Apply an algorithm to recover from the deadlock.

1) If resources have single instance:

In this case for Deadlock detection we can run an algorithm to check for
cycle in the Resource Allocation Graph. Presence of cycle in the graph is the
sufficient condition for deadlock.

In the above diagram, resource 1 and resource 2 have single instances. There
is a cycle R1 → P1 → R2 → P2. So, Deadlock is Confirmed.
2) If there are multiple instances of resources:
Detection of the cycle is necessary but not sufficient condition for
deadlock detection, in this case, the system may or may not be in
deadlock varies according to different situations.

Contact: 7008443534, 9090042626 21 | P a g e

Subject: Operating System
Created By: Asst. Prof. SK ABDUL ISRAR College: ABA, BLS

Recovery from Deadlock

When a Deadlock Detection Algorithm determines that a deadlock has occurred in
the system, the system must recover from that deadlock. There are two approaches
of breaking a Deadlock:

1. Process Termination:
To eliminate the deadlock, we can simply kill one or more processes. For this, we
use two methods:

• (a). Abort all the Deadlocked Processes:

Aborting all the processes will certainly break the deadlock, but with a great
expense. The deadlocked processes may have computed for a long time and
the result of those partial computations must be discarded.
• (b). Abort one process at a time until deadlock is eliminated:
Abort one deadlocked process at a time, until deadlock cycle is eliminated from
the system. Due to this method, there may be considerable overhead, because
after aborting each process, we have to run deadlock detection algorithm to
check whether any processes are still deadlocked.

2. Resource Preemption:
To eliminate deadlocks using resource preemption, we preepmt some resources
from processes and give those resources to other processes. This method will raise
three issues –
• (a). Selecting a victim:
We must determine which resources and which processes are to be preempted
and also the order to minimize the cost.
• (b). Rollback:
We must determine what should be done with the process from which
resources are preempted. One simple idea is total rollback. That means abort
the process and restart it.
• (c). Starvation:
In a system, it may happen that same process is always picked as a victim. As
a result, that process will never complete its designated task. This situation is
called Starvation and must be avoided. One solution is that a process must be
picked as a victim only a finite number of times.

Contact: 7008443534, 9090042626 22 | P a g e