Vad är race conditions, och hur förhindrar mutexes och semaphores dem?

Question

IT Interview Practice · Accepted Answer

När flera threads delar data kan deras operationer flätas samman (interleave) mitt i en flerstegsuppdatering, vilket ger en race condition — en bugg där utfallet beror på oförutsägbar timing. Synkronisering är den uppsättning verktyg som tvingar fram säker ordning.

Problemet: en race condition

count++ ser atomiskt ut men är egentligen read-modify-write:

## Problemet: en race condition

`count++` ser atomiskt ut men är egentligen 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         ┘
```

Fönstret mellan att läsa och skriva är en **critical section** — kod som rör delat tillstånd och inte får köras samtidigt.

## Verktygen

- **Mutex (lock)** — mutual exclusion: bara en thread håller den åt gången; andra blockeras tills den släpps. Omslut den kritiska sektionen:

```c
pthread_mutex_lock(&m);
count++;                 // kritisk sektion — exklusivt
pthread_mutex_unlock(&m);
```

- **Semaphore** — en räknare som tillåter upp till *N* samtidiga innehavare. En binär semaphore (N=1) fungerar som ett lock; en counting semaphore begränsar t.ex. en connection pool till N användare. Används även för **signalering** mellan threads (producer/consumer).
- **Condition variable** — låter en thread sova tills ett predikat blir sant (t.ex. "kön inte tom"), och vakna utan busy-waiting.
- **Atomic operations** — hårdvaruinstruktioner som compare-and-swap (CAS) som gör read-modify-write odelbart, vilket möjliggör lock-free-räknare.

## Fallgropar

Locks löser races men inför nya risker: **deadlock** (threads som väntar på varandras locks), **priority inversion** och **contention** (threads serialiseras, vilket dödar parallellism). Tumregeln: håll kritiska sektioner **korta**, och skaffa alltid flera locks i en **konsekvent global ordning**.

## Varför det är viktigt

Samtidighetsbuggar hör till de svåraste att hitta — de är icke-deterministiska och försvinner ofta under en debugger. Intervjuare vill se att du kan *upptäcka* en critical section, välja rätt primitiv (mutex vs semaphore vs atomic) och resonera om felmoderna (deadlock, contention). Detta gäller direkt för varje flertrådad server, delad cache eller räknare.

Problemet: en race condition

Verktygen

Fallgropar

Varför det är viktigt

Relaterade frågor