Critical Section problem in Operating System | OS Tutorials

A section of code within a process that requires access to shared resources and that must not be executed while another process is in a corresponding section of code. Only one program must be allowed in its critical section at a time.

The Critical Section Problem

Consider an operating system consisting of n processes { P₀, P₁,…..P_n-1 }. Each process has a segment of code, called a critical section, in which the process may be changing common variables, updating a table, and so on. The critical section problem is to design a protocol that the processes can use to cooperate. Each process must request permission to enter its critical section. The general structure of the typical process Pi is shown in Figure 1.

The entry section and exit section are enclosed in boxes to highlight these important segments of code. A solution to the critical-section problem must satisfy the following three requirements:

1. Mutual Exclusion: It guarantees that at most one process is in a critical section for shared data at any given time. A critical section implementation also guarantees that any process wishing to enter the critical section would not be delayed indefinitely, i.e., starvation should not occur.
2. Progress: 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.
3. Bounded Waiting: There exists a bound, or limit, on the number of times that other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is granted.

Example Showing Mutual Exclusion using Critical Regions

• Since we need four conditions to hold to have a good solution to a race condition. These are as
  1. No two processes may be simultaneously inside their critical regions.
  2. No assumptions may be made about speeds or the number of CPUs.
  3. No process running outside its critical region may block other processes.
  4. No processes should have to wait forever to enter their critical region.
• The expected behaviour is depicted in Figure 2.

• At time T₁, process A enters its critical region. At time T₂, process B attempts to enter its critical region but fails because another process (process A) is already in its critical region, and we allow only one process to execute at a time.
• Hence, process B is temporarily suspended until time T₃. When A leaves its critical region (at time t₃), allowing B to enter immediately.
• Eventually, process B leaves (at time T₄), and hence we are back to the original situation with no processes in their critical regions.