Apa itu race condition, dan bagaimana mutex dan semaphore mencegahnya?

Question

IT Interview Practice · Accepted Answer

Ketika banyak thread berbagi data, operasi mereka bisa berselang-seling (interleave) di tengah sebuah pembaruan multi-langkah, menghasilkan race condition — bug di mana hasilnya bergantung pada timing yang tak terduga. Sinkronisasi adalah kumpulan alat yang memaksa pengurutan yang aman.

Masalahnya: sebuah race condition

tampak atomic tetapi sebenarnya adalah read-modify-write:

## Masalahnya: sebuah race condition

`count++` tampak atomic tetapi sebenarnya adalah 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         ┘
```

Jendela antara membaca dan menulis adalah sebuah **critical section** — kode yang menyentuh state bersama dan tidak boleh berjalan secara bersamaan.

## Alat-alatnya

- **Mutex (lock)** — mutual exclusion: hanya satu thread yang memegangnya pada satu waktu; yang lain memblok sampai ia dilepas. Bungkus critical section-nya:

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

- **Semaphore** — sebuah counter yang mengizinkan hingga *N* pemegang bersamaan. Semaphore biner (N=1) berperilaku seperti lock; counting semaphore membatasi, katakanlah, sebuah connection pool pada N pengguna. Juga dipakai untuk **signaling** antar thread (producer/consumer).
- **Condition variable** — memungkinkan sebuah thread tidur sampai sebuah predikat menjadi benar (mis. "queue tidak kosong"), bangun tanpa busy-waiting.
- **Operasi atomic** — instruksi hardware seperti compare-and-swap (CAS) yang melakukan read-modify-write secara tak terpisahkan, memungkinkan counter lock-free.

## Jebakan

Lock menyelesaikan race tetapi memperkenalkan risiko baru: **deadlock** (thread saling menunggu lock satu sama lain), **priority inversion**, dan **contention** (thread menjadi serial, mematikan paralelisme). Aturan praktisnya: jaga critical section tetap **pendek**, dan selalu ambil beberapa lock dalam **urutan global yang konsisten**.

## Mengapa ini penting

Bug concurrency termasuk yang paling sulit ditemukan — mereka nondeterministik dan sering lenyap di bawah debugger. Pewawancara ingin melihat bahwa Anda bisa *mengenali* sebuah critical section, memilih primitive yang tepat (mutex vs semaphore vs atomic), dan menalar mode kegagalannya (deadlock, contention). Ini berlaku langsung untuk server multithread, cache bersama, atau counter apa pun.

Masalahnya: sebuah race condition

Alat-alatnya

Jebakan

Mengapa ini penting

Pertanyaan terkait