Maharashtra Board of Technical Education, Mumbai.

Government Polytechnic, Solapur.

DIPLOMA COMPUTER ENGINEERING

Academic Year 2021-2022.
A
MICRO-PROJECT REPORT
ON

Deadlock Handling
Submitted by:

Roll Enrollment Student Name

no. No.
30 2200150159 Diksha N. Birajdar

84 2200150221 Shrushti R. Ghante

Submitted To: R. V. Mundhe

1
 CERTIFICATE
Certified that this Micro-Project Report

Deadlock Handling
Is the work of

Roll Enrollment Student Name

no. No.
30 2200150159 Diksha N. Birajdar

84 2200150221 Shrushti R. Ghante

The students of Semester Third Subject Name – Environment Study (EST

- 22517) Diploma in Computer Engineering, 2024-2025.
This report is partial fulfilment for the award of the Micro-Project
Diploma in Computer Engineering by MSBTE, Mumbai.
Guide Name - R. V. Mundhe
Date & Sign -

H.O.D – PRINCIPAL

2
 Acknowledgement

I would like to sincerely thank my guide, Prof. R. V, Mundhe for helping

us with the structure of our micro project and guiding us on the important
points. He also cleared all our doubts about the project. We are very
grateful for his constant support, cooperation, and help. His
encouragement helped us overcome many challenges in the project.

We would also like to thank our Principal, HOD, and other faculty
members from our second-year department for their support and
motivation.

Finally, we have completed our micro project as per our syllabus and
department requirements. Once again, a big thank you to our respected
Principal, HOD, and faculty members for their help in completing the
project.

Thank you!

3
 Abstract

Deadlocks are a phenomenon in operating systems where two or more processes

are blocked indefinitely, each waiting for the other to release a resource. This
report explores the concept of deadlocks, their causes, and various handling
techniques. We discuss the necessary conditions for deadlocks to occur,
including mutual exclusion, hold and wait, no pre-emption, and circular wait.
We then examine different approaches to deadlock handling, such as
prevention, avoidance, and detection and recovery. The report also covers
various algorithms and techniques used in deadlock handling, including banker's
algorithm, wait-die algorithm, and deadlock detection using graphs. Finally, we
discuss the trade-offs and limitations of different approaches and provide
conclusions and future directions for research in deadlock handling.

4
 Introduction

In the realm of operating systems, deadlocks are a perennial problem that

can bring entire systems to a grinding halt. A deadlock occurs when two
or more processes are blocked indefinitely, each waiting for the other to
release a resource. This stubborn standoff can lead to decreased system
performance, wasted resources, and even complete system failure.

As the complexity of modern systems grows, so does the likelihood of

deadlocks. Therefore, understanding and addressing deadlocks is crucial
for building efficient, reliable, and scalable systems. This report delves
into the world of deadlock handling, exploring the causes, consequences,
and solutions to this pressing problem.

We will examine the necessary conditions for deadlocks to occur, discuss

various approaches to prevention, avoidance, and detection, and
investigate algorithms that help recover from deadlocks. By grasping the
concepts and techniques presented in this report, we can develop more
robust and resilient systems that minimize the impact of deadlocks.

5
AGENDA
 Deadlock
 Deadlock Problem & Example- Bridge Crossing Problem
 The cause, System Model & Normal Resource Allocation Operation
 Necessary conditions for deadlock
 Methods for handling Deadlock
 Resource Allocation Graph (RAG)
 Deadlock Prevention
 Deadlock Avoidance
 Recovery from Deadlock

DEADLOCK

 A deadlock is a situation wherein two or more competing actions

are each waiting for the other to finish, and thus neither ever does.
It is often seen in a paradox like the "chicken or the egg".
 It is a condition in which two computer programs sharing the same
resource are effectively preventing each other from accessing the
resource, resulting in both programs ceasing to function.

DEADLOCK PROBLEM
6
Deadlock refers to a specific condition when two or more processes are each
waiting for each other to release a resource, or more than two processes are
waiting for resources in a circular chain.
Example
 Client applications using the database may require exclusive access to
a table.
 Two client applications C1 and C2.
 If C1 holds lock on table, attempts to obtain on the other i.e., already
held by C2.
 This may lead to deadlock if the C2 application then attempts to
obtain the lock that is held by the C1 application.

Example- Bridge Crossing

 Each segment of road can be viewed as a resource

1. Car must own the segment under them
2. Must acquire segment that they are moving into

 For bridge: must acquire both halves

1. Traffic only in one direction at a time
2. Problem occurs when two cars in opposite directions on
bridge: each acquires one segment and needs next
 If a deadlock occurs, it can be resolved if one car backs up
(preempt resources and rollback)
1. Several cars may have to be backed up

7
MORE EXAMPLES
 “It takes money to make money.”
 “You can't get a job without experience; you can't get
experience without a job.”

THE CAUSE OF DEADLOCKS

 Each process needing what another process has. This results is
blocking from sharing resources such as memory, devices, links.

SYSTEM MODEL
 A system consists of a finite no. of resources for no. of competing
processes:
 Resource types R1, R2, . . ., Rm
 CPU cycles, memory space, files and I/O devices

NORMAL RESOURCE ALLOCATION OPERATION

Each resource type Ri has Wi instances. Each process utilizes a resource as
follows:
 Request a resource: if request not granted, then process should wait to
acquire.
 Use the resource: process can operate on the resources.
 Release the resource: the process releases the resources.

8
DEADLOCK CHARACTERIZATION

Necessary Conditions for Deadlock to occur: Deadlock can arise if

following four conditions hold simultaneously:
 Mutual exclusion: only one process at a time can use a resource.
 Hold and wait: a process holding at least one resource is waiting to
acquire additional resources held by other processes.
 No preemption: a resource can be released only voluntarily by the
process holding it, after that process has completed its task.
 Circular wait: there exists a set {P0, P1, …, P0} of waiting
processes such that P0 is waiting for a resource that is held by P1,
P1 is waiting for a resource that is held by P2, …, Pn–1 is waiting
for a resource that is held by Pn, and P0 is waiting for a resource
that is held by P0.

9
RESOURCE ALLOCATION GRAPH (RAG)
A visual (mathematical ) way to determine if a deadlock has, or may occur.
• G = ( V, E )The graph contains nodes and edges.
 V Nodes consist of processes = { P1, P2, P3, ...} and resource
types { R1, R2, ...}
 E Edges are (Pi, Rj) or (Ri, Pj)
• An arrow from the process to resource indicates the process is
requesting the resource. An arrow from resource to process shows an
instance of the resource has been allocated to the process.
• Process is a circle, resource type is square; dots represent number of
instances of resource in type. Request points to square,
assignment comes from dot.
If the graph contains no cycles, then no process is deadlocked.
• If there is a cycle, then:
 If resource types have multiple instances per resource type, then
possibility of deadlock MAY exist.
 If each resource type has one instance per resource type, then
deadlock has occurred.

Resource allocation graph

10
Resource Allocation Graph Allocation Graph with a Cycle
with a Deadlock but No Deadlock Resource

DEADLOCK PREVENTION:

1. Mutual exclusion:
 Automatically holds for printers and other non-sharables.
 Shared entities (read only files) don't need mutual exclusion (and
aren’t susceptible to deadlock.)
 Prevention not possible, since some devices are intrinsically non
sharable

2. Hold and wait:

 Collect all resources before execution.
 A particular resource can only be requested when no others are being
held. A sequence of resources is always collected beginning with the
same one.
 Utilization is low, starvation possible.

11
3. No pre-emption:
 Release any resource already being held if the process can't get an
additional resource.
 Allow pre-emption - if a needed resource is held by another process,
which is also waiting on some resource, steal it. Otherwise wait.

4. Circular wait:
 Number resources and only request in ascending order.

DEADLOCK AVOIDANCE

 If there is 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.
 The rule is simple that If a request allocation would cause an unsafe
state, do not honor that request.

DEADLOCK AVOIDANCE(CON)

 Requires that the system has some additional a priori information

available.
 Simplest and most useful model requires that each process declare the
maximum number of resources of each type that it may need.
 The deadlock-avoidance algorithm dynamically examines the
resource-allocation state to ensure that there can never be a circular-
wait condition.
 Resource-allocation state is defined by the number of available and
allocated resources, and the maximum demands of the processes.

12
SAFE STATE

 When a process requests an available resource, system must decide if

immediate allocation leaves the system in a safe state.
 System is in safe state if there exists a sequence <P1, P2, …, Pn> of ALL
the processes is the system such that for each Pi, the resources that Pi can
still request can be satisfied by currently available resources + resources
held by all the Pj, with j < i.
 That is:
o If Pi resource needs are not immediately available, then Pi can wait
until all Pj have finished. When Pj is finished,
o Pi can obtain needed resources, execute, return allocated resources,
and terminate.
o When Pi terminates, Pi +1 can obtain its needed resources, and so
on.

BANKER’S ALGORITHM

 Multiple instances.
 Each process claims maximum resource needs a priori.
 When a process requests a resource it may have to wait.
 When a process gets all of its resources it must return them in a
finite amount of time.

DATA STRUCTURES FOR BANKER’S ALGORITHM

 Let n = number of processes and m = number of resources types

 Available: Vector of length m. If Available[j] = k, there are k instances of
resource type Rj available.
 Max: n x m matrix. If Max [i,j] = k, then process Pi may request at most k
instances of resource type Rj.
 Allocation: n x m matrix. If Allocation[i,j] = k then Pi is currently
allocated k instances of Rj.
 Need: n x m matrix. If Need[i,j] = k, then Pi may need k more instances
of Rj to complete its task.
 Need [i,j] = Max[i,j] – Allocation [i,j].

13
 CONCLUSION

Deadlock represents a significant challenge in the realm of operating systems

and resource management. It arises when processes become indefinitely
blocked, each waiting for resources held by others, leading to a complete halt
in system operations. By recognizing the four necessary conditions for
deadlock—mutual exclusion, hold and wait, no pre-emption, and circular
wait—developers and system administrators can implement effective
strategies to prevent or resolve such situations.

14