What is Critical Section in Operating System?

Imagine you’re using a shared printer at your office. If two people try to print at the same time, their documents could get mixed up. That’s why there must be a system in place to manage who uses the printer and when. In the world of operating systems, this kind of situation, where multiple programs (or processes) try to access shared resources like files, printers, or memory is very common.

To manage this safely, the concept of a Critical Section is introduced. It plays a crucial role in concurrent programming to prevent problems like data inconsistency, race conditions, and deadlocks.

Let’s dive deep into what a critical section is, why it’s important, and how operating systems handle it.

Definition of Critical Section

A Critical Section is a part of a program where shared resources (like variables, data structures, or devices) are accessed and modified.

Since multiple processes or threads might try to use the same resource simultaneously, the critical section must be executed by only one process at a time to ensure data integrity.

Why is the Critical Section Important?

When multiple processes access and manipulate shared data concurrently, it may lead to unexpected and incorrect results. For example:

• Two banking apps simultaneously trying to update your balance
• A file being read and written at the same time

Without proper synchronization, you may face:

• 🌀 Race conditions
• ❌ Data inconsistency
• 💥 System crashes

The critical section problem arises when we need to design a mechanism to let only one process execute in the critical section at any given time.

Structure of a Process with Critical Section

A process that uses a shared resource generally has four sections:

Entry Section → Critical Section → Exit Section → Remainder Section

• Entry Section: Requests permission to enter the critical section
• Critical Section: Code that accesses the shared resource
• Exit Section: Releases the resource, allowing others to enter
• Remainder Section: Rest of the code that does not access shared resources

The Three Key Requirements (Critical Section Problem)

Any solution to the critical section problem must satisfy the following three requirements:

1. Mutual Exclusion

Only one process should be in the critical section at a time.

2. Progress

If no process is in the critical section, the next process wanting to enter should be allowed to proceed.

3. Bounded Waiting

Each process should have a limited wait time before it can enter the critical section again (i.e., no starvation).

How Do We Solve the Critical Section Problem?

Several techniques are used to implement synchronization and solve the critical section problem:

1. Software-Based Solutions

These do not rely on any special hardware and include:

• Peterson’s Algorithm
• Dekker’s Algorithm
• Lamport’s Bakery Algorithm

They are mainly used for educational purposes and small systems.

2. Hardware-Based Solutions

These depend on hardware support like:

• Test-and-Set Instruction
• Compare-and-Swap Instruction
• Disabling interrupts (in uniprocessor systems)

3. OS Support (Modern Approach)

Modern operating systems use synchronization primitives:

• Semaphores
• Mutexes
• Monitors
• Spinlocks
  These are implemented within system libraries or OS kernels.

Read Full Article on: Critical Section Problem

Real-World Example

Suppose two threads are trying to update the score of a game:

// Critical Section
score = score + 1;

If both threads run this line simultaneously, they might both read the same original score and write the same result—causing one update to be lost.

To fix this, we place it inside a lock:

lock();
score = score + 1;
unlock();

Now only one thread at a time can update the score, avoiding errors.

Summary Table