Deadlock vs Starvation vs Livelock

Introduction

Deadlock, starvation, and livelock are related because all three stop some work from completing. The difference lies in what the processes are doing while progress is failing.

In deadlock, a group is stuck. In starvation, one process keeps getting ignored. In livelock, processes remain active, but their actions still do not lead to completion.

Core Difference

The easiest way to separate these three ideas is to observe the system behavior. Is the process blocked, ignored, or repeatedly reacting without finishing?

• Deadlock: Processes wait for each other in a cycle, so none can continue.

• Starvation: One process waits for too long because other processes keep getting preference.

• Livelock: Processes keep changing state but make no useful progress.

Deadlock

Deadlock occurs when a set of processes or threads waits in a cycle, and no member of the cycle can move forward. Each process is waiting for a resource held by another process in the same group.

For example, suppose two threads need locks A and B:

• T1: Holds A and waits for B.

• T2: Holds B and waits for A.

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

Neither thread can continue because each one needs a lock held by the other. Common fix directions include lock ordering, deadlock avoidance, deadlock detection, and recovery.

Starvation

Starvation occurs when a process or thread waits for a very long time because the scheduling or resource policy keeps favoring others. The full system may still be running, but one unlucky task does not get a fair chance.

A common example is priority scheduling. If high-priority processes keep arriving, a low-priority process may remain ready but never get enough CPU time.

Starvation can also happen in resource policies. For example, if a lock or access policy repeatedly favors one class of requests, another process may keep waiting even though the system is not deadlocked.

Common fix directions include:

• Aging: Gradually increase the priority of a process the longer it waits.

• Fairness: Avoid policies that always favor the same type of task.

• Bounded waiting: Guarantee that a process will not wait forever before getting service.

Livelock

Livelock occurs when processes or threads keep taking actions, but those actions prevent useful completion. Unlike deadlock, the processes are not blocked; they are active.

A typical livelock pattern appears when two threads repeatedly try to avoid deadlock by releasing locks too quickly. If both follow the same retry behavior at the same time, they may keep colliding.

For example:

• Thread 1: Locks A, tries to lock B, and releases A if B is unavailable.

• Thread 2: Locks B, tries to lock A, and releases B if A is unavailable.

• Livelock: If both threads retry at the same time, they may repeatedly release and reacquire locks without making any progress.

The threads are doing work, changing state, and consuming CPU, but the actual goal is never completed. Common fix directions include random backoff, fixed ordering, or giving one side priority.

How to Recognize the Problem

Deadlock, starvation, and livelock can look similar from a user's point of view because some work is not finishing. The internal behavior tells the real story.

The important distinction is progress. Deadlock has no movement in the cycle, starvation has unfair progress, and livelock has movement without completion.

Summary

Deadlock, starvation, and livelock are all progress failures in operating systems and concurrent programs. Deadlock means a group is stuck in a circular wait, starvation means a task is repeatedly denied service, and livelock means tasks stay active but fail to complete useful work.

Their fixes also differ. Deadlock is handled through ordering, avoidance, detection, or recovery; starvation is reduced through fairness, aging, and bounded waiting; livelock is handled through random backoff, fixed ordering, or priority rules.