Wat zijn race conditions, en hoe voorkomen mutexes en semaforen ze?

Question

IT Interview Practice · Accepted Answer

Wanneer meerdere threads data delen, kunnen hun operaties interleaven midden in een update van meerdere stappen, wat een race condition oplevert — een bug waarbij de uitkomst afhangt van onvoorspelbare timing. Synchronisatie is de verzameling tools die een veilige volgorde afdwingen.

Het probleem: een race condition

lijkt atomair maar is eigenlijk read-modify-write:

## Het probleem: een race condition

`count++` lijkt atomair maar is eigenlijk 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         ┘
```

Het venster tussen lezen en schrijven is een **critical section** — code die gedeelde state aanraakt en niet gelijktijdig mag draaien.

## De tools

- **Mutex (lock)** — mutual exclusion: slechts één thread houdt hem tegelijk vast; andere blokkeren tot hij wordt vrijgegeven. Wikkel de critical section erin:

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

- **Semafoor** — een teller die tot *N* gelijktijdige houders toestaat. Een binaire semafoor (N=1) werkt als een lock; een tellende semafoor begrenst bijvoorbeeld een connection pool op N gebruikers. Wordt ook gebruikt voor **signaling** tussen threads (producer/consumer).
- **Condition variable** — laat een thread slapen tot een predicaat waar wordt (bv. "queue niet leeg"), en ontwaakt zonder busy-waiting.
- **Atomic operations** — hardware-instructies zoals compare-and-swap (CAS) die read-modify-write ondeelbaar uitvoeren, wat lock-free counters mogelijk maakt.

## Valkuilen

Locks lossen races op maar introduceren nieuwe risico's: **deadlock** (threads die op elkaars locks wachten), **priority inversion**, en **contention** (threads serialiseren, wat parallellisme doodt). De vuistregel: houd critical sections **kort**, en verkrijg meerdere locks altijd in een **consistente globale volgorde**.

## Waarom het belangrijk is

Concurrency-bugs behoren tot de moeilijkst te vinden — ze zijn niet-deterministisch en verdwijnen vaak onder een debugger. Interviewers willen zien dat je een critical section kunt *herkennen*, de juiste primitive kunt kiezen (mutex vs semafoor vs atomic), en over de faalvormen (deadlock, contention) kunt redeneren. Dit is direct van toepassing op elke multithreaded server, gedeelde cache of counter.

Het probleem: een race condition

De tools

Valkuilen

Waarom het belangrijk is

Gerelateerde vragen