Czym są race conditions i jak mutexy oraz semafory im zapobiegają?

Question

IT Interview Practice · Accepted Answer

Gdy wiele wątków współdzieli dane, ich operacje mogą się przeplatać (interleave) w środku wieloetapowej aktualizacji, tworząc race condition — bug, w którym wynik zależy od nieprzewidywalnego taktowania. Synchronizacja to zestaw narzędzi, które wymuszają bezpieczną kolejność.

Problem: race condition

wygląda na atomowe, ale w rzeczywistości jest to odczyt-modyfikacja-zapis (read-modify-write):

## Problem: race condition

`count++` wygląda na atomowe, ale w rzeczywistości jest to odczyt-modyfikacja-zapis (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         ┘
```

Okno między odczytem a zapisem to **sekcja krytyczna (critical section)** — kod, który dotyka współdzielonego stanu i nie może działać współbieżnie.

## Narzędzia

- **Mutex (lock)** — wzajemne wykluczanie: tylko jeden wątek trzyma go naraz; pozostałe blokują się, aż zostanie zwolniony. Owiń sekcję krytyczną:

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

- **Semafor** — licznik pozwalający na maksymalnie *N* jednoczesnych posiadaczy. Semafor binarny (N=1) działa jak lock; semafor zliczający ogranicza, powiedzmy, pulę połączeń do N użytkowników. Używany też do **sygnalizowania (signaling)** między wątkami (producent/konsument).
- **Zmienna warunkowa (condition variable)** — pozwala wątkowi spać, dopóki predykat nie stanie się prawdziwy (np. „kolejka niepusta"), budząc się bez aktywnego czekania (busy-waiting).
- **Operacje atomowe** — instrukcje sprzętowe jak compare-and-swap (CAS), które wykonują odczyt-modyfikację-zapis niepodzielnie, umożliwiając liczniki bez blokad (lock-free).

## Pułapki

Locki rozwiązują wyścigi, ale wprowadzają nowe ryzyka: **deadlock** (wątki czekające na wzajemne locki), **inwersję priorytetów (priority inversion)** i **rywalizację (contention)** (wątki serializują się, zabijając równoległość). Zasada praktyczna: trzymaj sekcje krytyczne **krótkie** i zawsze zdobywaj wiele locków w **spójnej globalnej kolejności**.

## Dlaczego to ważne

Bugi współbieżności należą do najtrudniejszych do znalezienia — są niedeterministyczne i często znikają pod debuggerem. Rozmówcy chcą zobaczyć, że potrafisz *dostrzec* sekcję krytyczną, wybrać właściwy prymityw (mutex vs semafor vs atomic) i rozumować o trybach awarii (deadlock, contention). Dotyczy to bezpośrednio każdego wielowątkowego serwera, współdzielonego cache'u czy licznika.

Problem: race condition

Narzędzia

Pułapki

Dlaczego to ważne

Powiązane pytania