Livelock in Operating System

In this article, you will learn about Livelock in the operating system.

What is Livelock?

Livelock happens when a request for an exclusive lock is continually denied due to multiple overlapping shared locks that keep interfering. The processes status continuously changes, prevents them from completing the task, and makes it even more difficult for them to complete the task.

It happens when multiple processes repeatedly perform the same interaction in reaction to changes in the other processes without performing any useful work. These processes are not in a waiting state and are running simultaneously, and it is different from a deadlock because all processes of deadlocks are in a state of waiting.

Examples of Livelock

Various examples of Livelock are as follows:

Example 1:

A common instance of Livelock is that when two persons meet face to face in a corridor, and both move aside to let the other pass. They end up going from side to side without making any progress because they are moving in the same direction simultaneously. So, they are failed to cross each other.

Example 2:

Another instance of Livelock is when two processes require two resources, and they use the primitive polling enter registry to get the required locks. If the first attempt fails, a second try is attempted. Let's suppose that:

1. Process A hold Y resource
2. Process B hold X resource
3. Process A require X resource
4. Process B require Y resource

Suppose that process A runs first and obtains data resource X, and process B runs second and obtains resource Y and no matter which process runs first neither process progress. Although, none of the processes is blocked. They use CPU resources continuously without making any progress, but they also halt any processing block. As a result, this is not a deadlock because no single process is halted, but you are in a condition that is similar to a deadlock, which is LIVELOCK.

What leads to Livelocks?

Livelock happens when the total permitted process in a given system must be defined by the number of entries in the process table. As a result, process table slots should be known as Finite Resources. If a fork fails because of a full table, the fork program should wait a random time before attempting again.

Take a look at a UNIX system with 100 process slots. 10 programs are running, each of which is responsible for creating 12 (sub)processes. After each process has created 9 new processes, the table has been exhausted by the 10 original and 90 new processes. Each of the 10 original processes has become stuck in a never-ending cycle of forking and failing, which is referred to as a deadlock. Although the chances of this occurring are minimal, but it may be possible.