Deadlock Avoidance: Identifying the Correct Algorithm Among Options

Verified Sources

Sep 12, 2026

Deadlock avoidance is a class of resource-allocation strategies that refuse to grant a request that would move the system into an unsafe state (i.e., a state where deadlock is possible). The canonical example in operating systems is the Banker's algorithm.

In contrast, options like round-robin are CPU scheduling policies rather than deadlock avoidance mechanisms, and “elevator” and “Karn’s” are not standard deadlock-avoidance algorithms in the classic OS taxonomy used in exams/textbooks.

A high-level decision rule for deadlock avoidance is:

Among the given choices, the deadlock avoidance algorithm is (i) Banker's algorithm.

Key terms you should recognize here:

Deadlock
Deadlock avoidance
Safe state
Resource allocation graph

Deadlock Avoidance (Banker's Algorithm) - OS Concepts

To map the multiple-choice options correctly, it helps to distinguish what kind of algorithm each option actually is:

(i) Banker's algorithm: designed specifically to avoid deadlocks by checking safety before granting resource requests. It matches the definition of deadlock avoidance.
(ii) Round-robin algorithm: a well-known time-slicing CPU scheduling approach. It does not analyze resource-allocation safety conditions, so it is not deadlock avoidance.
(iii) Elevator algorithm: typically refers to a disk head scheduling strategy (servicing requests like an elevator/SCAN). Again, not a resource-allocation deadlock method.
(iv) Karn's algorithm: “Karn’s algorithm” is not part of the standard OS deadlock avoidance/detection set used in canonical curricula and exam questions; it is therefore not the expected deadlock avoidance answer among these choices.

Why Banker's Algorithm is Deadlock Avoidance (Safety Check Process)

1
Step 1
Temporarily update the Available, Allocation, and Need structures as if the request were granted.
2
Step 2
Try to find a sequence of processes that can finish with the remaining resources.
3
Step 3
If such a sequence exists, the new state is safe → grant. If none exists, it’s unsafe → delay/deny.
4
Step 4
Repeat the safety check whenever a new request arrives.

Visualizing “safe vs unsafe”

A “safe” state means there exists at least one ordering of process completions that avoids deadlock. “Unsafe” does not mean deadlock is guaranteed immediately; it means deadlock is possible, so the system avoids granting actions that create such states.

Algorithm Type vs Relevance to Deadlock Avoidance

High relevance means the algorithm actively prevents unsafe resource-allocation grants.

Exam Strategy

If an option mentions resource allocation + safe/unsafe states, it’s usually deadlock avoidance. Round-robin and elevator are scheduling policies, not resource-allocation safety checks.

Common Confusion

Round-robin is about CPU time sharing. Deadlock is about processes waiting for resources. Don’t mix scheduling with deadlock-avoidance conditions.

Quick Explanations of Each Option

Knowledge Check

Question 1 of 3

Q1Single choice

Which one of the following is the deadlock avoidance algorithm?

Banker's algorithm

Round-robin algorithm

Elevator algorithm

Karn's algorithm

Explore Related Topics

Similarity Between SLR(1), LALR(1), and LR(1): Correct Choice and Learning Path

Applications of the Queue Data Structure (MCQ: Which option is correct?)

Justifying Why a Cycle in a Resource Allocation Graph Does Not Always Imply Deadlock

A cycle in a resource allocation graph (RAG) does not always imply deadlock; the conclusion hinges on whether each resource type involved has a single instance or multiple instances.

No cycle → the system cannot be deadlocked.
Cycle + every resource in the cycle has one instance ⇒ deadlock is guaranteed.
Cycle + any resource has multiple instances ⇒ deadlock is possible but not certain ( $\text{Cycle} \centernot\implies \text{Deadlock}$ ).
Thus a cycle is a necessary but not sufficient condition for deadlock in multi‑instance systems.
Example: with two instances of $R1$ and $R2$ , a cycle $P1 \rightarrow R2 \rightarrow P2 \rightarrow R1 \rightarrow P1$ can be broken when another process releases an instance.

Browse all research articles