Mik a race condition-ök, és hogyan előzik meg őket a mutexek és semaphore-ok?

Question

IT Interview Practice · Accepted Answer

Amikor több thread osztozik adatokon, a műveleteik átlapolódhatnak egy többlépéses frissítés közepén, race conditiont okozva — egy olyan bugot, ahol az eredmény kiszámíthatatlan időzítésen múlik. A szinkronizáció azoknak az eszközöknek a halmaza, amelyek biztonságos sorrendet kényszerítenek ki.

A probléma: egy race condition

A atominak tűnik, de valójában read-modify-write:

## A probléma: egy race condition

A `count++` atominak tűnik, de valójában 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         ┘
```

A beolvasás és az írás közötti ablak egy **critical section** — olyan kód, amely megosztott állapotot érint, és nem futhat egyidejűleg.

## Az eszközök

- **Mutex (lock)** — kölcsönös kizárás: egyszerre csak egy thread tartja; a többi blokkol, amíg fel nem szabadul. Csomagold be vele a critical sectiont:

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

- **Semaphore** — egy számláló, amely legfeljebb *N* egyidejű birtoklót enged meg. Egy bináris semaphore (N=1) lockként viselkedik; egy számláló semaphore például egy connection poolt korlátoz N felhasználóra. Threadek közti **jelzésre (signaling)** is használják (producer/consumer).
- **Condition variable** — hagyja, hogy egy thread aludjon, amíg egy feltétel igazzá válik (pl. "a queue nem üres"), busy-wait nélkül ébredve.
- **Atomi műveletek** — olyan hardveres utasítások, mint a compare-and-swap (CAS), amelyek oszthatatlanul végeznek read-modify-write-ot, lock-free számlálókat téve lehetővé.

## Buktatók

A lockok megoldják a race-eket, de új kockázatokat hoznak: **deadlock** (threadek egymás lockjaira várnak), **priority inversion** és **contention** (a threadek sorba rendeződnek, felszámolva a párhuzamosságot). Ökölszabály: tartsd **rövidnek** a critical section-öket, és több lockot mindig **konzisztens globális sorrendben** szerezz meg.

## Miért fontos

A konkurenciahibák a legnehezebben megtalálhatók közé tartoznak — nemdeterminisztikusak, és gyakran eltűnnek debugger alatt. Az interjúztatók azt akarják látni, hogy *ki tudod szúrni* egy critical sectiont, kiválasztod a helyes primitívet (mutex vs semaphore vs atomi), és át tudod gondolni a hibamódokat (deadlock, contention). Ez közvetlenül vonatkozik bármely többszálú szerverre, megosztott cache-re vagy számlálóra.

A probléma: egy race condition

Az eszközök

Buktatók

Miért fontos

Kapcsolódó kérdések