Was sind Race Conditions und wie verhindern Mutexes und Semaphoren sie?

Question

IT Interview Practice · Accepted Answer

Wenn mehrere Threads sich Daten teilen, können ihre Operationen mitten in einem mehrstufigen Update verschachteln (interleave) und eine Race Condition erzeugen — einen Bug, bei dem das Ergebnis von unvorhersehbarem Timing abhängt. Synchronisation ist die Menge an Werkzeugen, die eine sichere Reihenfolge erzwingen.

Das Problem: eine Race Condition

sieht atomar aus, ist aber in Wirklichkeit Read-Modify-Write:

## Das Problem: eine Race Condition

`count++` sieht atomar aus, ist aber in Wirklichkeit 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         ┘
```

Das Fenster zwischen Lesen und Schreiben ist eine **Critical Section** — Code, der geteilten Zustand berührt und nicht nebenläufig laufen darf.

## Die Werkzeuge

- **Mutex (Lock)** — gegenseitiger Ausschluss: nur ein Thread hält ihn gleichzeitig; andere blockieren, bis er freigegeben wird. Umschließe die Critical Section:

```c
pthread_mutex_lock(&m);
count++;                 // kritischer Abschnitt — exklusiv
pthread_mutex_unlock(&m);
```

- **Semaphore** — ein Zähler, der bis zu *N* gleichzeitige Halter erlaubt. Eine binäre Semaphore (N=1) wirkt wie ein Lock; eine zählende Semaphore begrenzt etwa einen Connection Pool auf N Nutzer. Wird auch zum **Signalisieren** zwischen Threads verwendet (Producer/Consumer).
- **Condition Variable** — lässt einen Thread schlafen, bis ein Prädikat wahr wird (z. B. "Queue nicht leer"), und weckt ihn ohne Busy-Waiting.
- **Atomare Operationen** — Hardware-Instruktionen wie Compare-and-Swap (CAS), die Read-Modify-Write unteilbar ausführen und lock-freie Zähler ermöglichen.

## Fallstricke

Locks lösen Races, führen aber neue Risiken ein: **Deadlock** (Threads warten auf die Locks des jeweils anderen), **Priority Inversion** und **Contention** (Threads serialisieren, was Parallelität zunichtemacht). Die Faustregel: halte Critical Sections **kurz** und akquiriere mehrere Locks immer in einer **konsistenten globalen Reihenfolge**.

## Warum es wichtig ist

Concurrency-Bugs gehören zu den am schwersten zu findenden — sie sind nichtdeterministisch und verschwinden oft unter einem Debugger. Interviewer wollen sehen, dass du eine Critical Section *erkennen*, das richtige Primitiv wählen (Mutex vs. Semaphore vs. Atomic) und über die Fehlermodi (Deadlock, Contention) nachdenken kannst. Das gilt direkt für jeden Multithreaded-Server, geteilten Cache oder Zähler.

Das Problem: eine Race Condition

Die Werkzeuge

Fallstricke

Warum es wichtig ist

Ähnliche Fragen