Que sont les race conditions, et comment les mutex et les sémaphores les empêchent-ils ?

Question

IT Interview Practice · Accepted Answer

Quand plusieurs threads partagent des données, leurs opérations peuvent s'entrelacer (interleave) au milieu d'une mise à jour en plusieurs étapes, produisant une race condition — un bug où le résultat dépend d'un timing imprévisible. La synchronisation est l'ensemble des outils qui imposent un ordre sûr.

Le problème : une race condition

semble atomique mais est en réalité un read-modify-write (lecture-modification-écriture) :

## Le problème : une race condition

`count++` semble atomique mais est en réalité un read-modify-write (lecture-modification-écriture) :

```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         ┘
```

La fenêtre entre la lecture et l'écriture est une **critical section** (section critique) — du code qui touche à l'état partagé et ne doit pas s'exécuter de façon concurrente.

## Les outils

- **Mutex (lock)** — exclusion mutuelle : un seul thread le détient à la fois ; les autres se bloquent jusqu'à sa libération. Enveloppez la critical section :

```c
pthread_mutex_lock(&m);
count++;                 // section critique — exclusif
pthread_mutex_unlock(&m);
```

- **Semaphore** — un compteur autorisant jusqu'à *N* détenteurs simultanés. Un sémaphore binaire (N=1) agit comme un lock ; un sémaphore à compteur plafonne, par exemple, un connection pool à N utilisateurs. Utilisé aussi pour la **signalisation (signaling)** entre threads (producer/consumer).
- **Condition variable** — permet à un thread de dormir jusqu'à ce qu'un prédicat devienne vrai (p. ex. « queue non vide »), en se réveillant sans busy-waiting.
- **Atomic operations** — des instructions matérielles comme compare-and-swap (CAS) qui effectuent le read-modify-write de manière indivisible, permettant des compteurs lock-free.

## Les pièges

Les locks résolvent les races mais introduisent de nouveaux risques : **deadlock** (des threads qui s'attendent mutuellement sur leurs locks), **priority inversion**, et **contention** (les threads se sérialisent, tuant le parallélisme). La règle empirique : gardez les critical sections **courtes**, et acquérez toujours plusieurs locks dans un **ordre global cohérent**.

## Pourquoi c'est important

Les bugs de concurrence sont parmi les plus difficiles à trouver — ils sont non déterministes et disparaissent souvent sous un débogueur. Les recruteurs veulent voir que vous pouvez *repérer* une critical section, choisir la bonne primitive (mutex vs semaphore vs atomic), et raisonner sur les modes de défaillance (deadlock, contention). Cela s'applique directement à tout serveur multithread, cache partagé ou compteur.

Le problème : une race condition

Les outils

Les pièges

Pourquoi c'est important

Questions connexes