What are race conditions, and how do mutexes and semaphores prevent them?

Question

IT Interview Practice · Accepted Answer

When multiple threads share data, their operations can interleave in the middle of a multi-step update, producing a race condition — a bug where the outcome depends on unpredictable timing. Synchronization is the set of tools that force safe ordering.

The problem: a race condition

count++ looks atomic but is really read-modify-write:

## The problem: a race condition

`count++` looks atomic but is really read-modify-write:

```c
// two threads, shared int count = 0, each does count++ once
// thread A: read count (0) ─┐           interleaving loses an update:
// thread B: read count (0) ─┤  both read 0, both write 1 → count == 1, not 2
// thread A: write 1         │
// thread B: write 1         ┘
```

The window between reading and writing is a **critical section** — code that touches shared state and must not run concurrently.

## The tools

- **Mutex (lock)** — mutual exclusion: only one thread holds it at a time; others block until it's released. Wrap the critical section:

```c
pthread_mutex_lock(&m);
count++;                 // critical section — exclusive
pthread_mutex_unlock(&m);
```

- **Semaphore** — a counter allowing up to *N* concurrent holders. A binary semaphore (N=1) acts like a lock; a counting semaphore caps, say, a connection pool at N users. Also used for **signaling** between threads (producer/consumer).
- **Condition variable** — lets a thread sleep until a predicate becomes true (e.g. "queue not empty"), waking without busy-waiting.
- **Atomic operations** — hardware instructions like compare-and-swap (CAS) that do read-modify-write indivisibly, enabling lock-free counters.

## Pitfalls

Locks solve races but introduce new risks: **deadlock** (threads waiting on each other's locks), **priority inversion**, and **contention** (threads serialize, killing parallelism). The rule of thumb: keep critical sections **short**, and always acquire multiple locks in a **consistent global order**.

## Why it matters

Concurrency bugs are among the hardest to find — they're nondeterministic and often vanish under a debugger. Interviewers want to see that you can *spot* a critical section, choose the right primitive (mutex vs semaphore vs atomic), and reason about the failure modes (deadlock, contention). This applies directly to any multithreaded server, shared cache, or counter.

The problem: a race condition

The tools

Pitfalls

Why it matters

Related questions