Vaidikalaya
Privious Next

Critical Section In Operating System

The critical section is the part of a program where shared resources (variables, files, database records, devices) are read or updated. Only one process is allowed inside the critical section at a time to maintain data consistency and prevent race conditions. These shared resources can be:

  • Shared variables or data structures
  • Files and databases
  • Printers or other I/O devices

The goal of a critical section in process synchronization is to protect shared resources and keep data consistent when multiple processes or threads run at the same time. Make sure that only one process at a time can access or modify shared data, so that no conflicts or wrong results occur.

Structure of a Critical Section

Here’s a simple conceptual structure of how a critical section is written in a program. This is language-independent and shows the key parts.


Entry Section:

The entry section is the first step in the typical structure of a process that needs to enter a critical section. It is the piece of code a process executes before entering the critical section. Its job is to ask for permission and check whether it is safe to enter, so that only one process can be inside the critical section at a time (mutual exclusion). The process waits in this section if another process is already inside the critical section.

Uses synchronization mechanisms like:

  • Locks / Mutex (lock() function)
  • Semaphores (wait() operation)
  • Flags or turn variables (Peterson’s solution, Dekker’s algorithm)
Critical Section:

Actual code where shared resources (variables, files, devices) are read or updated. Only one process/thread should execute here at a time.

Exit Section:

The process releases the lock or semaphore, allowing other processes to enter the critical section.

Remainder Section:

It is the Code that runs outside the critical section. It does not need synchronization because it does not touch shared resources.

do {
    wait(mutex);            // Entry Section (lock)
   
    // Critical Section
    shared_data = shared_data + 1;

    signal(mutex);          // Exit Section (unlock)
   
    // Remainder Section
    do_other_work();
} while (true);
wait(mutex) and signal(mutex) (or lock/unlock) ensure only one process is inside the critical section at any time.

Requirements of Critical Section Solutions

The critical section is the part of a process where shared resources (like data, files, printers) are accessed or updated. To avoid race conditions, the operating system (or programmer) must ensure that only one process at a time can execute inside its critical section.

Any mechanism used to protect the critical section (locks, semaphores, monitors, etc.) must satisfy three essential requirements.

1. Mutual Exclusion:

Only one process at a time is allowed inside the critical section. It prevents conflicts by ensuring no two processes update the shared resource simultaneously.

2. Progress:

If no process is in the critical section, and some processes want to enter, the choice of who enters next should not be postponed indefinitely. It ensures that the system continues to make progress rather than getting stuck.

3. Bounded Waiting:

Bounded waiting means that each process must have a limited waiting time. It should not wait endlessly to access the critical section. It prevents starvation, where one process is repeatedly bypassed while others get to execute.

What problems occur in a Critical Section if it is not handled properly?

A critical section is the part of a program where shared resources (data, files, devices) are accessed or modified. If more than one process or thread enters this section at the same time without synchronization, several serious problems can occur.

  • Race condition occurs when two or more processes attempt to update shared data at the same time, leading to unexpected results. Example: Two bank transactions modifying the same account balance simultaneously without synchronization may lead to incorrect final balance.
  • Deadlock occurs when two or more processes wait forever because each is holding a resource and waiting for another resource held by the others, usually due to improper locking order or circular waiting.
  • Starvation occurs when a process waits too long and never gets a chance to enter the critical section → it happens when higher-priority processes keep getting preference and there is no bounded waiting.

If a critical section is not protected with proper synchronization.

race conditions, data corruption, deadlocks, starvation, priority inversion, and CPU wastage (busy waiting) can occur. Correct synchronization ensures safe, fair, and efficient sharing of resources.
Privious Next