Apa iku race condition, lan kepiye mutex lan semaphore nyegah kuwi?

Question

IT Interview Practice · Accepted Answer

Nalika akeh thread nganggo bareng data, operasine bisa interleave ing tengah-tengah update multi-langkah, ngasilake race condition — bug sing kasile gumantung marang wektu sing ora bisa diramal. Sinkronisasi iku sakumpulan piranti sing meksa urutan sing aman.

Masalahe: race condition

count++ katon atomik nanging sabenere read-modify-write:

## Masalahe: race condition

`count++` katon atomik nanging sabenere 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         ┘
```

Jendhela antara maca lan nulis iku **critical section** — kode sing nyenggol state bareng lan ora kena mlaku bebarengan.

## Piranti-pirantine

- **Mutex (lock)** — mutual exclusion: mung siji thread nyekel ing sak wektu; liyane keblok nganti diuculake. Bungkus critical section-e:

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

- **Semaphore** — counter sing ngidini nganti *N* sing nyekel bebarengan. Semaphore biner (N=1) tumindak kaya lock; counting semaphore matesi, contone, connection pool ing N pangganggo. Uga dienggo kanggo **signaling** antar thread (producer/consumer).
- **Condition variable** — ngidini thread turu nganti sawijining predikat dadi bener (contone "queue ora kosong"), tangi tanpa busy-wait.
- **Operasi atomik** — instruksi perangkat keras kaya compare-and-swap (CAS) sing nglakoni read-modify-write kanthi ora kena dipara, mungkinake counter lock-free.

## Jebakan

Lock ngrampungake race nanging nggawa risiko anyar: **deadlock** (thread padha ngenteni lock siji lan sijine), **priority inversion**, lan **contention** (thread dadi urut, mateni paralelisme). Aturan umume: gawe critical section **cendhak**, lan tansah njupuk pirang-pirang lock kanthi **urutan global sing konsisten**.

## Kenapa iki penting

Bug concurrency klebu sing paling angel ditemokake — dheweke nondeterministik lan kerep ilang nalika dijalanke ing debugger. Pewawancara pengin ndeleng yen kowe bisa *ngenali* critical section, milih primitive sing bener (mutex vs semaphore vs atomic), lan menalar bab mode gagal (deadlock, contention). Iki ditrapake langsung ing server multithread, cache bareng, utawa counter apa wae.

Masalahe: race condition

Piranti-pirantine

Jebakan

Kenapa iki penting

Pitakon sing gegandhengan