---
title: "Race condition; critical section approaches"
subject: "Operating System"
chapter: 3
key: "semester_6/operating_system:race-condition-critical-section-approaches"
source: https://www.bctengineer.com/q/semester_6/operating_system/race-condition-critical-section-approaches
site: BCT Engineering
---

# Race condition; critical section approaches

Operating System · Chapter 3: Process Communication and Synchronization

- Asked in: 2070 Bhadra, 2+8 marks
- Video: [The Critical-Section Problem](https://www.youtube.com/watch?v=UtEORPakw5Y) — Neso Academy
- Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_6/operating_system/race-condition-critical-section-approaches
- Whole chapter: https://www.bctengineer.com/md/semester_6/operating_system/chapter-3

## Question

What is race condition and critical section problem? Explain all possible approaches to handle the situation "while one process is busy updating shared memory, no other process will enter its critical section and cause trouble".

## Short answer

A race condition occurs when multiple processes access shared data and the final result depends on scheduling order. The critical section problem asks for a protocol giving mutual exclusion, progress and bounded waiting. Approaches include disabling interrupts, lock variables, strict alternation, Peterson's algorithm, TSL, sleep/wakeup, semaphores, monitors and message passing.

## Answer

#### Race condition and critical section problem

A **race condition** occurs when two or more processes access shared data and the result depends on the exact order of execution. The part of the program that accesses the shared data is the **critical section (region)**. The **critical section problem** is to design a protocol so that when one process is executing in its critical section, no other process is allowed to execute in its critical section. A solution must satisfy:
1. mutual exclusion;
2. progress (a process outside the critical section must not block others);
3. bounded waiting (no starvation);
4. no assumptions about speed or number of CPUs.

#### Approaches to achieve mutual exclusion

**1. Disabling interrupts**: a process disables all interrupts just after entering its critical region and enables them before leaving. No clock interrupt means no preemption. Simple, but dangerous to give to user processes (they may never re-enable), and it does not work on multiprocessors.

**2. Lock variable (software)**: `while (lock != 0); lock = 1; ...critical...; lock = 0;`. Fails: two processes can both see `lock = 0` before either sets it, which is itself a race.

**3. Strict alternation**:
```c
/* Process 0 */ while (TRUE) { while (turn != 0); critical_region(); turn = 1; noncritical(); }
/* Process 1 */ while (TRUE) { while (turn != 1); critical_region(); turn = 0; noncritical(); }
```
Ensures mutual exclusion by busy waiting (spin lock), but violates condition 2 (progress): a slow process outside its critical region can block the other.

**4. Peterson's algorithm**: software solution for two processes using `turn` and `interested[]` flags; satisfies all conditions using busy waiting.
```c
void enter_region(int p) { int other = 1 - p;
    interested[p] = TRUE; turn = p;
    while (turn == p && interested[other] == TRUE); }
void leave_region(int p) { interested[p] = FALSE; }
```

**5. Hardware: TSL / XCHG instruction**: atomically reads and sets a lock word, so only one process gets the lock. Works for multiprocessors, but uses busy waiting.
```text
enter_region: TSL REGISTER,LOCK ; CMP REGISTER,#0 ; JNE enter_region ; RET
leave_region: MOVE LOCK,#0 ; RET
```

**6. Sleep and wakeup**: instead of busy waiting, a blocked process sleeps. The producer-consumer problem with plain sleep/wakeup can lose a wakeup signal (race on the `count` variable).

**7. Semaphores**: integer variable with atomic `down` and `up`; `mutex = 1` gives mutual exclusion: `down(&mutex); critical(); up(&mutex);` Blocked processes sleep, so no CPU is wasted.

**8. Monitors**: language construct in which only one process can be active inside the monitor; condition variables `wait/signal` are used for synchronization. Mutual exclusion is automatic.

**9. Message passing**: processes use `send` and `receive`; no shared variable is needed, so it also works in distributed systems.

Of these, 2, 3, 4, 5 use busy waiting; 6-9 block the waiting process. Semaphores and monitors are the practical choices for general use.

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. What is the main drawback of disabling interrupts for mutual exclusion?
   A. It causes busy waiting
   B. It needs a lock variable
   C. It works only on one process
   D. Unsafe for user processes and does not work on multiprocessors
   Answer: D. A user process might never re-enable interrupts, and disabling them affects only one CPU. (Key point: Disabling interrupts)

2. Why does the simple lock variable fail?
   A. Two processes can both see lock = 0 before either sets it
   B. The variable overflows
   C. It requires hardware support
   D. It blocks processes outside the region
   Answer: A. Testing and setting the lock are separate steps, so checking the lock is itself a race. (Key point: Lock variable flaw)

3. Which condition does strict alternation violate?
   A. Mutual exclusion
   B. A process outside its critical region must not block another
   C. Bounded memory use
   D. Single CPU assumption
   Answer: B. A slow process in its non-critical section can keep the turn and block the other process. (Key point: Strict alternation)

4. Which group of approaches uses busy waiting?
   A. Semaphores, monitors and message passing
   B. Sleep/wakeup and monitors
   C. Lock variable, strict alternation, Peterson and TSL
   D. Only message passing
   Answer: C. Approaches 2 to 5 spin; sleep/wakeup, semaphores, monitors and message passing block the waiting process. (Key point: Busy waiting vs blocking)

## Related in Operating System

- [Race condition; sleep() and wakeup()](https://www.bctengineer.com/question.md?key=semester_6%2Foperating_system%3Arace-sleep-wakeup) — Operating System, chapter 3
- [Critical section problem; why execute quickly](https://www.bctengineer.com/question.md?key=semester_6%2Foperating_system%3Acritical-section-thread-quick) — Operating System, chapter 3
- [Race condition; optimal page replacement limits](https://www.bctengineer.com/question.md?key=semester_6%2Foperating_system%3Arace-condition-optimal-limitation) — Operating System, chapter 3
- [Race condition example; Peterson's algorithm](https://www.bctengineer.com/question.md?key=semester_6%2Foperating_system%3Arace-condition-example-peterson) — Operating System, chapter 3
- [Race condition; mutual exclusion requirements](https://www.bctengineer.com/question.md?key=semester_6%2Foperating_system%3Arace-mutual-exclusion-requirements) — Operating System, chapter 3
- [Critical section; mutual exclusion](https://www.bctengineer.com/question.md?key=semester_6%2Foperating_system%3Acritical-section-mutual-exclusion-pc) — Operating System, chapter 3

## Related in other subjects

- [Race around condition; JK to SR conversion](https://www.bctengineer.com/question.md?key=semester_3%2Fdigital_logic%3Arace-around-jk-to-sr) — Digital Logic, chapter 6
- [Euler's formula: one end fixed, other hinged](https://www.bctengineer.com/question.md?key=semester_3%2Fstrength_of_materials%3Aeuler-one-fixed-one-hinged) — Strength of Materials, chapter 8, asked 2×
- [Critical gradient; quick condition in sand](https://www.bctengineer.com/question.md?key=semester_4%2Fsoil_mechanics%3Acritical-hydraulic-gradient-quick) — Soil Mechanics, chapter 6
- [Fixed shaft: end couples, diameter, section of no twist](https://www.bctengineer.com/question.md?key=semester_3%2Fstrength_of_materials%3Ashaft-fixed-ends-couples-no-twist) — Strength of Materials, chapter 6