Ce sunt race condition-urile și cum le previn mutex-urile și semafoarele?

Question

IT Interview Practice · Accepted Answer

Când mai multe thread-uri împart date, operațiile lor se pot întrepătrunde (interleave) în mijlocul unei actualizări în mai mulți pași, producând o race condition — un bug în care rezultatul depinde de un timing imprevizibil. Sincronizarea este setul de instrumente care impun o ordonare sigură.

Problema: o race condition

pare atomic, dar în realitate este read-modify-write (citește-modifică-scrie):

## Problema: o race condition

`count++` pare atomic, dar în realitate este read-modify-write (citește-modifică-scrie):

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

Fereastra dintre citire și scriere este o **critical section** — cod care atinge starea partajată și nu trebuie să ruleze concurent.

## Instrumentele

- **Mutex (lock)** — excludere mutuală: doar un thread îl deține la un moment dat; ceilalți se blochează până este eliberat. Împachetează critical section-ul:

```c
pthread_mutex_lock(&m);
count++;                 // secțiune critică — exclusiv
pthread_mutex_unlock(&m);
```

- **Semafor** — un contor care permite până la *N* deținători concurenți. Un semafor binar (N=1) se comportă ca un lock; un semafor de numărare limitează, să zicem, un connection pool la N utilizatori. Folosit și pentru **semnalizare** între thread-uri (producer/consumer).
- **Condition variable** — permite unui thread să doarmă până când un predicat devine adevărat (ex. „coada nu e goală"), trezindu-se fără busy-waiting.
- **Operații atomice** — instrucțiuni hardware precum compare-and-swap (CAS), care fac read-modify-write indivizibil, permițând contoare lock-free.

## Capcane

Lock-urile rezolvă race-urile, dar introduc riscuri noi: **deadlock** (thread-uri care așteaptă lock-urile unele altora), **priority inversion** și **contention** (thread-urile se serializează, ucigând paralelismul). Regula de bază: menține critical section-urile **scurte** și achiziționează întotdeauna mai multe lock-uri într-o **ordine globală consistentă**.

## De ce contează

Bug-urile de concurență sunt printre cele mai greu de găsit — sunt nedeterministe și adesea dispar sub un debugger. Intervievatorii vor să vadă că poți *identifica* o critical section, alege primitiva potrivită (mutex vs semafor vs atomic) și raționa despre modurile de eșec (deadlock, contention). Acest lucru se aplică direct oricărui server multithread, cache partajat sau contor.

Problema: o race condition

Instrumentele

Capcane

De ce contează

Întrebări conexe