Race condition nedir ve mutex ile semaphore bunları nasıl önler?

Question

IT Interview Practice · Accepted Answer

Birden çok thread veriyi paylaştığında, işlemleri çok adımlı bir güncellemenin ortasında iç içe geçebilir (interleave) ve bir race condition üretir — sonucun öngörülemez zamanlamaya bağlı olduğu bir bug. Senkronizasyon, güvenli sıralamayı zorlayan araçlar kümesidir.

Sorun: bir race condition

count++ atomik görünür ama aslında oku-değiştir-yaz'dır (read-modify-write):

## Sorun: bir race condition

`count++` atomik görünür ama aslında oku-değiştir-yaz'dır (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         ┘
```

Okuma ile yazma arasındaki pencere bir **critical section**'dır (kritik bölge) — paylaşılan duruma dokunan ve eşzamanlı çalışmaması gereken kod.

## Araçlar

- **Mutex (lock)** — karşılıklı dışlama (mutual exclusion): bir seferde yalnızca bir thread onu tutar; diğerleri serbest bırakılana kadar bloke olur. Critical section'ı sarmalayın:

```c
pthread_mutex_lock(&m);
count++;                 // kritik bölge — yalnızca bir thread
pthread_mutex_unlock(&m);
```

- **Semaphore** — en fazla *N* eşzamanlı tutucuya izin veren bir sayaç. İkili (binary) semaphore (N=1) bir lock gibi davranır; sayan (counting) bir semaphore ise örneğin bir connection pool'u N kullanıcıyla sınırlar. Ayrıca thread'ler arası **sinyalleşme (signaling)** için de kullanılır (producer/consumer).
- **Condition variable** — bir thread'in bir koşul doğru olana dek (ör. "queue boş değil") uyumasını, busy-wait yapmadan uyanmasını sağlar.
- **Atomic işlemler** — compare-and-swap (CAS) gibi donanım komutları; oku-değiştir-yaz'ı bölünmez biçimde yapar ve lock-free sayaçları mümkün kılar.

## Tuzaklar

Lock'lar race'leri çözer ama yeni riskler getirir: **deadlock** (thread'lerin birbirinin lock'unu beklemesi), **priority inversion** (öncelik tersine dönmesi) ve **contention** (thread'ler sıraya girer, paralelliği öldürür). Genel kural: critical section'ları **kısa** tutun ve birden çok lock'u her zaman **tutarlı bir global sırayla** edinin.

## Neden önemli

Eşzamanlılık (concurrency) bug'ları bulunması en zor olanlardandır — belirlenimci (deterministik) değildir ve genellikle debugger altında kaybolur. Mülakatçılar bir critical section'ı *fark edebildiğinizi*, doğru primitifi (mutex vs semaphore vs atomic) seçtiğinizi ve hata modları (deadlock, contention) üzerine akıl yürüttüğünüzü görmek ister. Bu, çok thread'li herhangi bir sunucuya, paylaşılan cache'e ya da sayaca doğrudan uygulanır.

Sorun: bir race condition

Araçlar

Tuzaklar

Neden önemli

İlgili sorular