第 9 关 · 锁与并发：spinlock、mutex 与 RCU

定位

第九关回答内核里最实际的问题：“互斥”到底有几种形态。答案是三种：忙等的（spinlock，拿不到就原地打转）、睡眠的（mutex，拿不到就让出 CPU），以及第三种“作弊”的——RCU，读端根本不拿锁。前两种的区别不在性能，而在上下文：持有自旋锁时你不能被调度走，拿互斥锁时你可以。

这一关的三个机制支点：qspinlock 的 32 位字（把 MCS 排队锁塞进 4 个字节）、mutex 的乐观自旋 + MCS 等待队列（先赌持有者马上释放，赌输了再睡）、RCU 的宽限期（读端零同步开销，写者等所有 CPU 过一次静默期）。M01 的 task_struct 在这里露面——mutex 的 owner 字段存的就是它；M03 的 slab 藏在 qnode、mutex_waiter 背后；M07 会给 mutex 的睡眠算一笔上下文切换的账。

核心机制深讲

9.1 qspinlock：把 MCS 排队锁塞进 4 个字节

现代内核的自旋锁是 qspinlock（kernel/locking/qspinlock.c），注释开宗明义：“This queued spinlock implementation is based on the MCS lock”——经典的 MCS 排队锁。但传统 MCS 需要 8 字节 tail 指针 + 每个节点 8 字节 next，而 spinlock_t 的 ABI 是 4 字节。做法是把 {tail, next->locked} 压缩进一个 u32（include/asm-generic/qspinlock_types.h）：

• bit 0–7：locked 字节（真正的锁位，只用 1 位，扩成一字节是为了原子字节写的性能）

• bit 8–15：pending 字节（第二个竞争者的“我先占个位”）

• bit 16–17：tail 索引（per-CPU 节点数组下标，嵌套层级）

• bit 18–31：tail CPU 号（+1 编码，0 表示无排队）

加锁分三档。无竞争 (0,0,0)：一次原子操作置 locked，即 (0,0,1)，这就是 fast path。第二个竞争者到来：先置 pending 位，然后自旋在锁字节上等持有者释放——(0,1,1) → (0,1,0) → (0,0,1)。只有第三个及以后的竞争者才进 MCS 队列：从 per-CPU 的 qnodes 数组取一个节点（4 个节点对应 task/softirq/hardirq/nmi 四层嵌套上下文，注释写得明明白白），xchg_tail 把自己挂到队尾，前驱的 next 指向自己，然后自旋在自己节点的 locked 上。

这是整个设计的精髓：等待者从不触碰锁的缓存行。传统 test-and-set 自旋锁里，N 个 CPU 自旋在同一个字上，每次释放都是一次缓存行广播风暴；排队之后，每个等待者只读自己的 per-CPU 节点，锁的缓存行只在“交接”那一刻传递一次。解锁时：如果队首是唯一的排队者，用 cmpxchg 把 tail 清零、锁位清零；否则只置锁位、唤醒 next 节点。

9.2 mutex：先赌一把，赌输了再睡

mutex_lock()（kernel/locking/mutex.c）的第一行就是全部哲学：

void __sched mutex_lock(struct mutex *lock)
{
	might_sleep();
	if (!__mutex_trylock_fast(lock))
		__mutex_lock_slowpath(lock);
}

__mutex_trylock_fast 是一次 atomic_long_try_cmpxchg_acquire(&lock->owner, 0, current)——把 owner 从 0 换成自己。owner 字段里存的是 task_struct 指针 | 标志位（M01 的老熟人）：MUTEX_FLAG_WAITERS（有人在等）、MUTEX_FLAG_HANDOFF / MUTEX_FLAG_PICKUP（直接交接）。

慢路径的第一步不是睡眠，而是乐观自旋（mutex_spin_on_owner）。注释写了 rationale：“if the lock owner is running, it is likely to release the lock soon”——如果持有者正在另一个 CPU 上跑，它大概率马上释放，自旋几十条指令远比两次上下文切换便宜。但有两个熔断条件（mutex_can_spin_on_owner）：持有者不在 CPU 上（被抢占了，自旋纯属烧电，用 owner_on_cpu / vcpu_is_preempted 检测），或者自己需要被调度（need_resched）。自旋者之间用 MCS 排队（注释原话：“The mutex spinners are queued up using MCS lock”），经 osq（optimistic spin queue）实现，保证只有一个自旋者在和持有者竞速。

自旋也抢不到，才真正睡眠：__mutex_add_waiter 把自己挂到等待链表（队首指针 first_waiter），置 WAITERS 位，schedule()。解锁时唤醒队首；还有一招更狠的 __mutex_handoff：解锁者直接把锁交接给指定的等待者（置 PICKUP），跳过竞速，防饥饿。两条铁律写在 mutex_lock 的文档注释里：might_sleep()——中断上下文不许拿 mutex；递归加锁不允许。

9.3 自旋锁 vs 睡眠锁：不是性能之争，是上下文之争

新手常问“哪个更快”，这是问错了问题。选型只看两条：

• 持有锁时能不能被调度走？spinlock 忙等——如果持有者被调度走，等待者在空转烧 CPU，所以自旋锁临界区里禁止调度、禁止睡眠，临界区必须短。中断处理函数里只能用自旋锁（不能睡）。mutex 睡眠——持有者被调度走天经地义，临界区可长，但拿锁路径上有 might_sleep()，中断上下文碰不得。

• 等待时 CPU 干什么？自旋锁：烧。互斥锁：让给别人。用错的代价不对称：该睡的时候自旋，烧的是电；该自旋的时候睡，多付两次上下文切换（M07 的账）。

一句话：临界区短 + 不能睡 → spinlock；临界区长 + 能睡 → mutex。内核里大量的“先自旋后睡眠”混合策略（mutex 的乐观自旋就是），本质是在赌“持有者是不是马上就完事”。

9.4 RCU：读端不拿锁的作弊

RCU（Read-Copy Update）的读者长这样（include/linux/rcupdate.h:1435）：

static __always_inline void rcu_read_lock(void)
{
	__rcu_read_lock();
	__acquire_shared(RCU);
	rcu_lock_acquire(&rcu_lock_map);
}

非抢占内核下 __rcu_read_lock() 就是 preempt_disable()；可抢占内核下是 current->rcu_read_lock_nesting++。注意共同点：没有原子操作，没有共享缓存行写入——计数器是 per-task 的。读端临界区的全部成本，就是禁止抢占期间“不被换出去”。这就是 deck 里“读者零开销”的底气：对比自旋锁/互斥锁每次加锁的原子 cmpxchg，RCU 读端的扩展性是另一个量级。

作弊的代价全在写者。写者不原地改，而是复制一份、改副本、一次指针发布切换新版本。旧版本不能立即释放——可能还有读者正读着它。两种等法（include/linux/rcupdate.h:62 起）：call_rcu(head, func) 把释放回调排队，宽限期结束后异步执行，写者不等；synchronize_rcu()（定义在 kernel/rcu/tree.c:4879）同步等一个宽限期（grace period）。

宽限期的定义是 RCU 全机制最漂亮的一句：所有 CPU 都经过一次静默期（quiescent state）。静默期指“不可能再持有旧版本引用的状态”：上下文切换、进入用户态、CPU idle 都是（kernel/rcu/tree.c 里 rcu_softirq_qs、“scheduler is a quiescent state”的注释即是此意）。一旦每个 CPU 都静默过一次，旧版本上就不可能还有读者——释放安全。这就是“写者等一个静默期”的全部含义。

所以 RCU 是代价转移：把“每次读的同步成本”搬到“每次写的等待成本”+“旧版本内存翻倍”。读多写少（路由表、dentry 缓存的读路径）是稳赚；写频繁时宽限期追不上更新速度，旧版本堆积成山——那就别用 RCU。

9.5 锁自带的内存屏障（M18 预告）

qspinlock.c 里藏着一段注释，把锁和内存屏障的关系说透了：pending 等待循环“must be a load-acquire such that we match the store-release that clears the locked bit and create lock sequentiality”——加锁是 acquire，解锁是 release，两者配对才构成“锁的顺序性”。源码里 smp_cond_load_acquire、smp_wmb、smp_rmb 嵌在加锁/解锁路径各处：锁从来不只是“互斥”，它是“互斥 + 内存屏障”的打包。屏障的完整语义（acquire/release 到底保证什么、编译器和 CPU 各重排什么）是 M18 的主场，这里只记结论：能正确用锁，就已经用对了 90% 的屏障场景。

9.6 lockdep：让死锁死在测试阶段

内核有个运行时锁正确性检查器 lockdep，原理简单粗暴：给每把锁注册一个 lock_class（mutex_init → lockdep_init_map_wait，mutex.c:268），运行时记录“谁在拿着 A 的时候拿了 B”，一旦加锁顺序成环，立刻 splat 报错——死锁不必真的死一次，画出环就够了。RCU 也有自己的 lockdep map（rcu_lock_map，RCU_LOCKDEP_WARN）：没进 rcu_read_lock() 就解引用 __rcu 指针，调试内核会当场抓现行。代价是运行时开销，所以只在 CONFIG_DEBUG_LOCK_ALLOC / CONFIG_PROVE_RCU 的调试内核里全开。

为什么这样设计

为什么 qspinlock 要搞 MCS 排队，而不是简单的 test-and-set？

因为缓存行风暴。test-and-set 下 N 个 CPU 自旋在同一个锁字上，每次持有者释放都是一次写广播，所有等待者的缓存行同时失效、同时重读——CPU 越多越慢。排队之后，等待者自旋在自己的 per-CPU 节点上，锁的缓存行只在“持有者→队首”交接时传递一次。从 O(N) 的广播退化成 O(1) 的点对点传递，顺带还拿到了 FIFO 公平性。代价是 4 字节里塞下 tail+pending+locked 的编码杂技——为了兼容 spinlock_t 的旧 ABI，值得。

为什么 mutex 睡眠前要先乐观自旋，而不是直接睡？

因为睡眠贵：一次 schedule() 进、一次唤醒出，是两次上下文切换（M07 会算这笔账，微秒级）。而“持有者正在别的 CPU 上跑、几十纳秒后释放”是高频场景——自旋几十条指令赌赢，省掉两次切换；赌输（持有者被抢占/临界区长）才付睡眠的钱。mutex_can_spin_on_owner 的 owner_on_cpu 检查就是止损线：持有者都不在 CPU 上了，自旋每一圈都是纯浪费。

为什么 RCU 不给读者加个轻量锁（比如 per-CPU 计数），而要写者等宽限期？

因为读端的任何共享状态都是扩展瓶颈。per-CPU 计数看似无竞争，但写者要“等所有读者退完”就得扫所有 CPU 的计数器——CPU 越多，写的代价越大，读多写少的场景直接反杀。RCU 的宽限期把“等读者”翻译成“等静默期”：写者不跟踪任何读者，只等一个全局可观测的事件（所有 CPU 调度过一次）。协调成本从 O(读者数) 降到 O(1) 个等待，代价是写延迟和旧版本内存——读多写少时，这买卖稳赚。

与已学模块的关联

• M01 · task_struct：mutex 的 owner 字段存的就是 task_struct 指针（| flags）——“谁拿着锁”在内核里就是“哪个 task”。M01 的 D 状态从锁视角看更清楚：D 状态进程卡在临界区里，如果临界区拿的是自旋锁，调度和睡眠都是非法的——这就是 D 状态“连 SIGKILL 都杀不掉”的锁解释。

• M03 · slab：qnode（per-CPU 排队节点）、mutex_waiter、rcu_head 都是高频小对象，活在 slab 里——锁的扩展性一半在算法，一半在“节点分配不成为新的瓶颈”。

• M04 · 页表/TLB：RCU“复制-发布”依赖的指针发布语义，底层是内存屏障（M18 展开）；M04 COW 的“复制-按需”是同一思想在内存管理战场的版本。

• M07 · 上下文切换（前瞻）：mutex 睡眠 = 两次上下文切换，M07 会量化这笔开销——到时候回看 9.2 的乐观自旋，就知道它在省什么钱。

• M11/M12 · 前瞻：io_uring 的提交完成队列、ext4 的 journal，都是“高并发 + 正确性”的锁试验场，本关的选型框架到时候直接套用。

自测

出题原则：10 题中记忆性题目不超过 3 道，其余为应用/推理/权衡类——场景预测、设计 trade-off 比较、从代码路径找问题、解释“为什么这样设计而不是那样”。难度递进，最后两道需要想一会儿。

Q1. qspinlock 的 32 位字里有哪三个字段？各占多少位？（bit 0–7 / 8–15 / 16–31 分别是什么）

Q2. 第二个竞争者置 pending 位后自旋在锁字节上——为什么不直接进 MCS 队列？pending 机制省掉了什么？

Q3. mutex 的 owner 字段除了 task_struct 指针还藏了什么？MUTEX_FLAG_HANDOFF / PICKUP 是干什么的？

Q4. 中断处理函数（hardirq 上下文）里能调用 mutex_lock() 吗？能调用 spin_lock() 吗？分别为什么？

Q5. mutex 乐观自旋的两个熔断条件是什么？如果持有者被抢占（不在 CPU 上）了还继续自旋，会发生什么？

Q6. 64 核机器上 200 个线程抢一把 qspinlock，等待者们在自旋什么？对比经典 test-and-set 自旋锁，缓存行流量差在哪？

Q7. 非 PREEMPT_RCU 内核里，rcu_read_lock() 到底执行了什么指令？为什么说读端“零开销”——它真的什么都没做吗？

Q8. 写者用 RCU 更新了一个链表：发布新版本后，能立即 kfree 旧节点吗？grace period 到底在“等”什么，给出可观测的定义？

Q9. 读写比 1:1 的场景用 RCU 保护一个频繁更新的结构，会发生什么？RCU 的代价具体转移到了哪两个地方？

Q10. 设计题：一个计数器要在“进程上下文”和“hardirq 中断处理函数”之间共享并递增，可选 spinlock / mutex / RCU / atomic_t。逐个排除并给出最终选型，说明每个被排除者的死因。

延伸阅读

• kernel/locking/qspinlock.c —— queued_spin_lock_slowpath，MCS 排队实现本体（已核实存在，652 行）

• kernel/locking/mutex.c —— __mutex_trylock_fast / __mutex_lock_slowpath，乐观自旋（已核实存在，1664 行）

• kernel/rcu/tree.c —— synchronize_rcu（约 4879 行处），宽限期检测（已核实存在，7075 行）

• include/linux/rcupdate.h —— rcu_read_lock / call_rcu 接口与注释（已核实存在，2029 行）

bit: 31            18 17 16 15         8 7          0
     +----------------+----- +-------------+-----------+
     | tail cpu (+1)  | idx  | pending     | locked    |
     +----------------+------+-------------+-----------+
       14 bits          2 bits   8 bits        8 bits
状态机：(0,0,0) --trylock--> (0,0,1) 拿锁
        (0,0,1) --第2人--> (0,1,1) pending，自旋锁字节
        (0,1,1) --释放--> (0,1,0) --> (0,0,1) 队首拿锁
        第3人起：xchg_tail 进 MCS 队列，自旋在自己的 per-CPU node 上

mutex_lock()
 ├─ fast: cmpxchg(owner: 0 → current) 成功 → 返回
 └─ slow: __mutex_lock_slowpath()
      ├─ 乐观自旋 mutex_spin_on_owner()
      │   熔断：!owner_on_cpu(owner) 或 need_resched() → 停
      │   抢到 → 返回（自旋者经 MCS/osq 排队，只一个竞速）
      └─ 睡眠：__mutex_add_waiter 挂 first_waiter 链表
          置 MUTEX_FLAG_WAITERS → schedule()
解锁：唤醒队首；或 __mutex_handoff 直接交接 (PICKUP)

写者：复制 → 改副本 → 一次指针发布（新版本上线）
  ├─ call_rcu(head, func)：回调排队，写者不等
  └─ synchronize_rcu()：同步等一个 grace period
       grace period 结束 ⟺ 所有 CPU 都经过一次静默期
       CPU0: 上下文切换 ✓   CPU1: 进入用户态 ✓   CPU2: idle ✓
读端 rcu_read_lock()：preempt_disable()（非PREEMPT_RCU）
  → 零原子操作、零共享缓存行写入 —— “不被调度走”即“不静默”