Open In App

Progress of a process

Improve
Improve
Like Article
Like
Save
Share
Report

During the execution of a number of processes simultaneously, it might so happen that the order of execution of the statements in the critical section affects the final state of the values in the critical section. This is nothing but a race condition and gives rise to inconsistencies in the code. These are removed with the help of mutual exclusion, but there might still be a chance of starvation of other processes because of it. When this starvation extends to infinity, it leads to a deadlock.

Hence, mutual exclusion alone cannot guarantee the simultaneous execution of processes without any problems – a second condition known as progress is required to ensure no deadlock occurs during such execution.

A formal definition of progress is stated by Galvin as:

“If no process is executing in its critical section and some processes wish to enter their critical sections, then only those processes that are not executing in their remainder section can participate in deciding which will enter its critical section next, and this selection cannot be postponed indefinitely.”

This is a lot of stuff to take in at once, so let’s use an example to see how valid our statement is. Suppose in the clothes section of a departmental store, a boy A and a girl B want to use the changing room.

Boy A decides to use the changing room first, but cannot come to the decision as to how many clothes to take inside with him. As a result, even though the changing room is empty, girl B (who has made up her decision as to how many clothes to try out) cannot enter the changing room as she is obstructed by boy A.

In other words, boy A prevents girl B from using the changing room even though he doesn’t need to use it. This is what the concept of progress was made to prevent.

According to the main definition of progress, the only processes that can participate in the decision-making as to who can enter the critical section are those that are about to enter the critical section or are executing some code before entering the critical section. Processes that are in their reminder section, which is the section succeeding the critical section, are not allowed to participate in this decision-making process.

The main job of progress is to ensure one process is executing in the critical section at any point in time (so that some work is always being done by the processor). This decision cannot be “postponed indefinitely” – in other words, it should take a limited amount of time to select which process should be allowed to enter the critical section. If this decision cannot be taken in a finite time, it leads to a deadlock.


Last Updated : 03 Apr, 2020
Like Article
Save Article
Previous
Next
Share your thoughts in the comments
Similar Reads