Deadlock Conditions in Operating Systems

Introduction

Deadlock can occur only when four necessary conditions hold together. These conditions are mutual exclusion, hold and wait, no preemption, and circular wait.

They are also called Coffman conditions. They do not describe four different types of deadlock; they describe the required situation in which a deadlock becomes possible.

The Four Conditions for Deadlock

The four deadlock conditions work like ingredients. If a deadlock has already happened, all four conditions must be present. But if all four conditions are possible in a system, deadlock is not guaranteed in every execution because timing and resource availability also matter.

These conditions are important because deadlock prevention works by breaking at least one of them. If even one condition is removed, that particular deadlock pattern cannot form.

Mutual Exclusion

Mutual exclusion means at least one resource is non-shareable. Only one process or thread can use that resource at a time.

Locks are the clearest example. If Thread 1 holds a lock, Thread 2 cannot use that same lock until Thread 1 releases it. Other examples include some files, devices, database rows, or exclusive kernel resources.

Mutual exclusion is often necessary in operating systems because shared data must be protected from unsafe simultaneous access. The problem begins when such exclusive resources are combined with waiting patterns.

Hold and Wait

Hold and wait means a process or thread already owns one resource and asks for another resource without releasing the first one. It is not simply waiting; it is waiting while still occupying something.

For example, a thread may hold lock A and then request lock B. If another thread needs lock A to move forward, the first thread is now part of a risky waiting situation.

This condition matters because it allows resources to remain occupied even when the holder cannot currently continue.

No Preemption

No preemption means the operating system cannot forcibly take a resource away from the process or thread that holds it. The resource must be released voluntarily by its owner.

For many locks and exclusive resources, this behavior is expected. If the system randomly takes a lock away in the middle of a critical section, shared data may become inconsistent. That is why no preemption is practical in many cases, but it also contributes to deadlock.

Circular Wait

Circular wait means the waiting relationship forms a cycle. Each process or thread is waiting for a resource held by another member of the same cycle.

In such a cycle, no member can continue because the resource each one needs is held by another blocked member. This is the most visible pattern in many deadlock examples.

Circular wait must be interpreted carefully when resources have multiple instances. If another usable instance of a resource is available, a visible cycle may show deadlock possibility, not always a confirmed deadlock.

Applying the Conditions to Two Locks

Consider two threads and two locks, A and B. Thread T1 holds A and waits for B, while Thread T2 holds B and waits for A.

The waiting cycle is: T1 => waits for B => held by T2 => waits for A => held by T1

Now the four conditions can be checked:

• Mutual exclusion: A and B are locks, so only one thread can hold each lock at a time.

• Hold and wait: T1 holds A while waiting for B, and T2 holds B while waiting for A.

• No preemption: A cannot be forcibly taken from T1, and B cannot be forcibly taken from T2.

• Circular wait: T1 waits for T2, and T2 waits for T1.

This example satisfies all four deadlock conditions, so deadlock can occur. Still, timing matters. If T1 finishes and releases both locks before T2 reaches the conflicting point, that execution may not deadlock.

How Deadlock Prevention Breaks Conditions

Deadlock prevention means designing the system so that at least one Coffman condition cannot hold. The idea is simple, but the practical cost depends on the resource and system design.

• Break mutual exclusion: Make the resource shareable where possible, or provide another usable instance.

• Break hold and wait: Require a process to request all needed resources together before execution begins.

• Break no preemption: Allow resources to be released, rolled back, or reassigned when it is safe.

• Break circular wait: Force every process or thread to request resources in a fixed global order.

For two locks A and B, fixed ordering is especially useful. If every thread must request A first and then B, one thread may wait at A, but it will not hold B while waiting for A. The opposite-order cycle is removed.

Common Confusions

Waiting alone is not deadlock. A process may wait for I/O, a lock, or a device and then continue normally once the resource becomes available.

The four Coffman conditions are also not four separate bugs. They are necessary conditions that must hold together. If deadlock has occurred, all four are present; if one is impossible, that deadlock pattern is prevented.

Summary

Deadlock conditions are the four necessary requirements for deadlock: mutual exclusion, hold and wait, no preemption, and circular wait. They explain how processes or threads can become permanently blocked while holding and requesting shared resources.

Deadlock prevention works by breaking at least one of these conditions. In practice, this may involve sharing resources, requesting resources together, allowing safe preemption, or enforcing a fixed resource order to remove circular wait.