0% found this document useful (0 votes)
6 views76 pages

4778 3 71 Module 3 Deadlock

The document provides an in-depth overview of deadlocks in operating systems, including their definition, characterization, and methods for handling them. It outlines the conditions necessary for deadlocks to occur, such as mutual exclusion and circular wait, and discusses strategies for prevention, avoidance, detection, and recovery. Additionally, it explains algorithms like the Resource Allocation Graph and Banker's Algorithm used to manage resources and ensure system safety.

Uploaded by

mr.kerry.cloud
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views76 pages

4778 3 71 Module 3 Deadlock

The document provides an in-depth overview of deadlocks in operating systems, including their definition, characterization, and methods for handling them. It outlines the conditions necessary for deadlocks to occur, such as mutual exclusion and circular wait, and discusses strategies for prevention, avoidance, detection, and recovery. Additionally, it explains algorithms like the Resource Allocation Graph and Banker's Algorithm used to manage resources and ensure system safety.

Uploaded by

mr.kerry.cloud
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 76

MODULE III(Part 2)

DEADLOCKS
Deadlock : Definition
System Model
• System consists of different resources
• Resource types: R1, R2, . . ., Rm
• CPU cycles, memory space, I/O devices
•A process in operating system uses resources in the following way:
1. Request
• The process requests the resource.
• 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.
2. Use
• The process can operate on the resource (for example, if the resource is a
printer, the process can print on the printer).
3. Release
• The process releases the resource.
• The request and release of resources may be system calls
• Examples are the request() and release() device, open() and close() file, and
allocate() and free() memory system calls.
• Similarly, the request and release of semaphores can be accomplished through
the wait() and signal() operations on semaphores or through acquire() and
release() of a mutex lock.
• A system table records whether each resource is free or allocated.
• For each resource that is allocated, the table also records the process to which
it is allocated.
• 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.
Deadlock Characterization
• A deadlock situation can arise if
the following four conditions hold
simultaneously in a system:

1. Mutual exclusion
2. Hold and wait
3. No preemption
4. Circular wait
1. Mutual exclusion
• Only one process can use a resource at a time.
• At least one resource must be held in a nonsharable mode.
• If another process requests that resource, the requesting process must
be delayed until the resource has been released.

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 P0.
Resource-Allocation Graph (RAG)
Example: Resource allocation graph with a
Deadlock

• Two cycles exist in the system:


P1 → R1 → P2 → R3 → P3 → R2 → P1
P2 → R3 → P3 → R2 → P2
• 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.

● If no cycle in RAG – NO DEADLOCK


● If cycle exist in RAG – CHANCE FOR DEADLOCK
• 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 or may not
exist.
• If each resource type has exactly one instance, then a cycle implies
that a deadlock has occurred.
• If each resource type has several instances, then a cycle does not
necessarily imply that a deadlock has occurred.
Conclusion:
● If graph contains no cycles ⇒ no deadlock

● If graph contains a cycle ⇒


● if only one instance per resource type, then deadlock
● if several instances per resource type, possibility of deadlock
Example: Resource allocation graph without Deadlock

In this example also, we have


a cycle:
P1 → R1 → P3 → R2 → P1
But there is no deadlock.
Observe that process P4 may
release its instance of resource
type R2. That resource can
then be allocated to P3,
breaking the cycle.
Deadlock Handling
Methods for Handling Deadlocks
1. We can use a protocol to prevent or avoid deadlocks, ensuring that
the system will never enter a deadlocked state Deadlock Prevention
and Avoidance
2. We can allow the system to enter a deadlocked state, detect it, and
recover. Deadlock Detection
and Recovery
3. We can ignore the problem altogether and pretend that deadlocks
never occur in the system.
Methods for Handling Deadlocks
1. Deadlock Prevention
2. Deadlock Avoidance
3. Deadlock Detection
4. Deadlock Recovery
1. 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.
1. Eliminate Mutual Exclusion :

● Make resources sharable


● But certain resources are basically non-sharable.
● Sharable : read-only files
● Non-sharable : mutex locks
2. Eliminate Hold and Wait
● Must guarantee that whenever a process requests a resource, it does
not hold any other resources.
● Methods:
1. Require process to request and be allocated all its resources before it
begins execution.
2. If a process holding some resources and requesting for additional
resource, it must release the acquired resources first.
● Disadvantages:
1. Low resource utilization
2. Starvation possible
3. Eliminate No Preemption

● Resources can be preempted from processes.

● Method 1
• If a process that is holding some resources, requests another resource
that cannot be immediately allocated to it, then all resources currently
being held are released.
• Preempted resources are added to the list of resources for which the
process is waiting.
• Process will be restarted only when it can regain its old resources, as
well as the new ones that it is requesting.
● Method 2
Case1:
• If a process request some resources, we first check whether they are available.
• If they are, allocate them.

Case2:
• If they are not, we check whether they are allocated to some other process that is waiting
for additional resources.
• If so pre-empt from that process and allocate to current process.

Case3:
• 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, 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.
4. Eliminate Circular Wait

● Each resource will be assigned with a numerical number.

● A process can request the resources in increasing/decreasing order of


numbering.

● For example:

• If P1 process is allocated R5 resources, now next time if P1 ask for R4 or


R3 (lesser than R5), such request will not be granted, request for resources
more than R5 only will be granted.
• Let R = {R1, R2, ..., Rm} be the set of resource types.
• We assign to each resource type a unique integer number
• Formally, we define a one-to-one function F: R → N, where N is the set of
natural numbers.
• For example,
F(tape drive) = 1
F(disk drive) = 5
F(printer) = 12
• 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 only if
F(Rj) > F(Ri)
2. Deadlock Avoidance

● Requires that the system has some additional prior information available.

● Simplest and most useful model requires that each process declares the
maximum number of resources of each type that it may need.
Safe and unsafe states

● A state of the system is called safe:


● if the system can allocate all the resources requested by all the processes in some
order without entering into deadlock.
● a system is in a safe state only if there exists a safe sequence.
● safe sequence is an order {P1,P2,P3..,Pn}in which processes can be allocated
requests safely

● If the system cannot fulfill the request of all processes then the state of the system is
called unsafe.

● An unsafe state may lead to a deadlock


Safe, Unsafe, Deadlock State

If a system is in safe state ⇒ no deadlocks

If a system is in unsafe state ⇒ possibility of deadlock

Avoidance ⇒ ensure that a system will never enter an unsafe state.


● The key of deadlock avoidance approach is when the request is made for resources
then the request must only be approved in the case if the resulting state is also a safe
state.
Deadlock Avoidance Algorithms

1. Resource Allocation Graph Algorithm


• Used when only single instance of each resource type are
present

2. Bankers Algorithm
• Used when multiple instances of a resource type are present
1. Resource-Allocation Graph Algorithm
● Used if single instance of each resource type
● Edges
● Request edge
● Assignment edge
● Claim edge

● Claim edge: Pi → Rj indicated that process Pi may request resource Rj in future,


represented by a dashed line.
● Claim edge converts to request edge when a process requests a resource.
● Request edge converts to an assignment edge when the resource is allocated to the
process.
● When a resource is released by a process, assignment edge reconverts to a claim edge.
Resource-Allocation Graph Algorithm

● The request can be granted only if converting the request edge to an assignment edge
does not result in the formation of a cycle in the resource allocation graph.
Resource-Allocation Graph

Unsafe State in RAG


2. Banker’s Algorithm

• The resource-allocation-graph algorithm is not applicable to a resource


allocation system with multiple instances of each resource type.
• In such cases we use the banker’s algorithm.
• The name was chosen because the algorithm could be used in a
banking system to ensure that the bank never allocates its available
cash in such a way that it could no longer satisfy the needs of all its
customers.
Banker’s Algorithm

a) Safety Algorithm
- algorithm for finding out whether or not a system is in a safe state
(using a safe sequence).

b) Resource-Request Algorithm
- algorithm for determining whether requests can be safely granted.
• 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.
• We need the following data structures, where n is the number of processes
in the system and m is the number of resource types:
Updated Available
Final Safe Sequence
Problem 1
Problem 3
a) Safety Algorithm
• We can now present the algorithm for finding out whether or not a system is
in a safe state. This algorithm can be described as follows:
b) Resource-Request Algorithm
• Next, we describe the algorithm for determining whether requests can be
safely granted.
• Let Requesti be the request vector for process Pi . If Requesti [ j] == 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:
Tutorial 3 : Q1
Q2
• Given the following snapshot of a system at time T0. Find whether the
system is in a safe state using Banker's algorithm. If P1 generates a
request for (0,4,2,0), can the request be granted immediately?
3. Deadlock Detection
• To detect deadlock there are two options based on the instances of
resource type:
• Single Instance of Each Resource Type
• Several Instances of a Resource Type
a) Single Instance of Each Resource Type
• Deadlock detection algorithm 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 Pi to Pj in a wait-for graph implies that
process Pi is waiting for process Pj to release a resource that Pi needs.
• 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.
b) 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.
• A deadlock detection algorithm is applicable to such a system.

• The algorithm employs several time-varying data structures that are similar to
those used in the banker’s algorithm:

• Available. A vector of length m indicates the number of available


resources of each type.
• Allocation. An n × m matrix defines the number of resources of each type
currently allocated to each process.
• Request. An n × m matrix indicates the current request of each process.
4. Recovery from Deadlock

• 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 preempt some resources from one or more of the
deadlocked processes.
a) 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.
Many factors may affect which process is chosen, including:
1. What the priority of the process is?
2. How long the process has computed and how much longer the process
will compute before completing its designated task?
3. How many and what types of resources the process has used (for example,
whether the resources are simple to preempt)?
4. How many more resources the process needs in order to complete?
5. How many processes will need to be terminated?
6. Whether the process is interactive or batch?
b) Resource Preemption
• To eliminate deadlocks using resource preemption, we successively preempt some
resources from processes and give these resources to other processes until the
deadlock cycle is broken.
• If preemption is required to deal with deadlocks, then three issues need to be
addressed:
1. Selecting a victim
2. Rollback
3. Starvation
1. Selecting a victim.
-Which resources and which processes are to be preempted?

2. Rollback.
-If we preempt a resource from a process, what should be done with that process?

3. Starvation.
-How do we ensure that starvation will not occur? That is, how can we guarantee
that resources will not always be preempted from the same process.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy