Çfarë janë race conditions, dhe si i parandalojnë mutex-et dhe semaphore-t?

Question

IT Interview Practice · Accepted Answer

Kur shumë thread-e ndajnë të dhëna, operacionet e tyre mund të ndërthuren (interleave) në mes të një përditësimi me shumë hapa, duke prodhuar një race condition — një bug ku rezultati varet nga koha e paparashikueshme. Sinkronizimi është grupi i mjeteve që imponojnë renditje të sigurt.

Problemi: një race condition

duket atomik por në të vërtetë është read-modify-write:

## Problemi: një race condition

`count++` duket atomik por në të vërtetë është 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         ┘
```

Dritarja midis leximit dhe shkrimit është një **critical section** — kod që prek gjendjen e përbashkët dhe nuk duhet të ekzekutohet njëkohësisht.

## Mjetet

- **Mutex (lock)** — përjashtim reciprok: vetëm një thread e mban në një kohë; të tjerët bllokohen derisa të lirohet. Mbështill critical section-in:

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

- **Semaphore** — një numërues që lejon deri në *N* mbajtës njëkohësisht. Një semaphore binar (N=1) vepron si një lock; një counting semaphore kufizon, të themi, një connection pool në N përdorues. Përdoret gjithashtu për **sinjalizim (signaling)** midis thread-eve (producer/consumer).
- **Condition variable** — lejon një thread të flejë derisa një predikat të bëhet i vërtetë (p.sh. "queue jo bosh"), duke u zgjuar pa busy-waiting.
- **Atomic operations** — instruksione harduerike si compare-and-swap (CAS) që bëjnë read-modify-write në mënyrë të pandashme, duke mundësuar numërues lock-free.

## Kurthet

Locks-at i zgjidhin race-t por sjellin rreziqe të reja: **deadlock** (thread-e që presin locks e njëri-tjetrit), **priority inversion**, dhe **contention** (thread-et serializohen, duke vrarë paralelizmin). Rregulli i përgjithshëm: mbaji critical section-et **të shkurtra**, dhe merri gjithmonë locks e shumta në një **rend global të qëndrueshëm**.

## Pse ka rëndësi

Bug-et e concurrency-t janë ndër më të vështirët për t'u gjetur — janë jodeterministikë dhe shpesh zhduken nën një debugger. Intervistuesit duan të shohin se ti mund të *dallosh* një critical section, të zgjedhësh primitivin e duhur (mutex vs semaphore vs atomic), dhe të arsyetosh rreth mënyrave të dështimit (deadlock, contention). Kjo zbatohet drejtpërdrejt për çdo server multithread, cache të përbashkët, ose numërues.

Problemi: një race condition

Mjetet

Kurthet

Pse ka rëndësi

Pyetje të ngjashme