什么是 race condition，mutex 和 semaphore 如何防止它们？

Question

IT Interview Practice · Accepted Answer

当多个线程共享数据时，它们的操作可能在一次多步更新的中途**交错（interleave）**，产生一个 **race condition**——结果取决于不可预测的时序的 bug。**同步（synchronization）** 就是强制安全次序的一整套工具。

## 问题：一个 race condition

`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）** —— 互斥：同一时刻只有一个线程持有它；其他线程阻塞直到它被释放。把 critical section 包起来：

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

- **Semaphore** —— 一个计数器，允许至多 *N* 个持有者并发。二元 semaphore（N=1）表现得像一个 lock；计数 semaphore 则给例如 connection pool 设定 N 个用户的上限。也用于线程间的**信号传递（signaling）**（producer/consumer）。
- **Condition variable** —— 让一个线程休眠直到某个谓词变为真（例如“队列非空”），无需 busy-wait 即可唤醒。
- **Atomic operation** —— 像 compare-and-swap（CAS）这样的硬件指令，不可分割地完成读-改-写，从而实现 lock-free 的计数器。

## 陷阱

Lock 解决了 race，但引入了新风险：**deadlock**（线程互相等待对方的 lock）、**priority inversion**（优先级反转）和 **contention**（线程被串行化，扼杀了并行性）。经验法则：让 critical section **短**，并且总是以一个**一致的全局顺序**获取多个 lock。

## 为什么这很重要

并发（concurrency）bug 属于最难查找的一类——它们是非确定性的，往往在 debugger 下就消失了。面试官想看到你能*发现*一个 critical section、选对 primitive（mutex vs semaphore vs atomic），并对失败模式（deadlock、contention）进行推理。这直接适用于任何多线程 server、共享 cache 或计数器。

问题：一个 race condition

工具

陷阱

为什么这很重要

相关问题