レースコンディションとは何で、mutex と semaphore はどうやってそれを防ぐのですか?

Question

IT Interview Practice · Accepted Answer

複数のスレッドがデータを共有すると、それらの操作が多段更新の途中で **インターリーブ (interleave)** し、**レースコンディション (race condition)** — 結果が予測不能なタイミングに依存するバグ — を生みます。**同期 (synchronization)** は安全な順序を強制するツール群です。

## 問題: レースコンディション

`count++` はアトミックに見えますが、実際には 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         ┘
```

読み取りと書き込みの間の窓が **critical section** — 共有状態に触れ、並行実行してはならないコード — です。

## ツール

- **Mutex (lock)** — 相互排他: 一度に 1 つのスレッドだけが保持し、他は解放されるまでブロックされます。critical section を包みます:

```c
pthread_mutex_lock(&m);
count++;                 // クリティカルセクション — 排他的
pthread_mutex_unlock(&m);
```

- **Semaphore** — 最大 *N* 個の同時保持者を許すカウンタ。バイナリ semaphore (N=1) は lock のように振る舞い、カウンティング semaphore はたとえば connection pool を N ユーザーに制限します。スレッド間の **シグナリング (signaling)** (producer/consumer) にも使われます。
- **Condition variable** — スレッドを述語が真になるまで (例: 「キューが空でない」) スリープさせ、ビジーウェイトなしで起こします。
- **Atomic operation** — compare-and-swap (CAS) のようなハードウェア命令で、read-modify-write を不可分に行い、lock-free なカウンタを可能にします。

## 落とし穴

lock はレースを解決しますが新たなリスクを持ち込みます: **デッドロック** (スレッドが互いの lock を待つ)、**優先度逆転 (priority inversion)**、**競合 (contention)** (スレッドが直列化され並列性が失われる)。経験則: critical section を **短く** 保ち、複数の lock は常に **一貫したグローバル順序** で獲得すること。

## なぜ重要なのか

並行性 (concurrency) のバグは最も見つけにくい部類です — 非決定的で、デバッガの下ではしばしば消えます。面接官は、あなたが critical section を *見抜き*、正しいプリミティブ (mutex vs semaphore vs atomic) を選び、故障モード (デッドロック、競合) を推論できるかを見たいのです。これはあらゆるマルチスレッドサーバー、共有キャッシュ、カウンタに直接当てはまります。

問題: レースコンディション

ツール

落とし穴

なぜ重要なのか

関連する質問