2. Linux内核同步机制总览：自旋锁、信号量、互斥锁、读写锁、RCU、futex的定位与关系
Linux内核作为多任务、多CPU的操作系统核心，必须提供一套完备的同步互斥机制来保护共享资源，防止竞态条件。本章从宏观视角梳理内核中主要的同步原语，明确各自的定位、适用场景以及它们之间的层次关系，为后续深入剖析futex与读写锁奠定基础。
2.1 同步机制全景图
内核同步机制可以按照等待方式（忙等待 vs 阻塞睡眠）和保护粒度（临界区大小）进行分类。下图展示了核心同步原语在系统中的位置与关系。
2.2 核心同步原语详解
2.2.1 自旋锁 (Spinlock)
自旋锁是最基础的同步原语。当锁被持有时，等待线程会原地循环（忙等待）直到锁可用。它适用于临界区极短且不允许睡眠的上下文（如中断处理程序）。
- 优点：无上下文切换开销，响应快。
- 缺点：浪费CPU周期，不适合长时间持有。
- 变体：raw_spinlock（原始自旋锁）、spin_lock_irqsave（关中断版本）。
2.2.2 信号量 (Semaphore)
信号量是一个计数器，允许多个线程同时访问资源（计数信号量）或作为互斥体（二值信号量）。线程在获取不到信号量时会主动睡眠，让出CPU。
- 核心操作：
down()（P操作，减计数，可能睡眠）、up()（V操作，增计数，唤醒等待者）。 - 适用场景：生产者-消费者模型、资源池管理。
- 注意：信号量没有“所有者”概念，任何线程都可以释放。
2.2.3 互斥锁 (Mutex)
互斥锁是信号量的特化版本，但语义更严格：谁持有谁释放，且支持递归和优先级继承（PI），用于防止优先级反转。
- 数据结构：
struct mutex，包含owner字段和等待队列。 - 特性：支持调试（CONFIG_DEBUG_MUTEXES）、支持饥饿避免。
- 与信号量区别：mutex只能用于互斥，性能优于信号量。
2.2.4 读写锁 (RW Lock)
读写锁区分读操作和写操作。多个读者可以同时持有锁，但写者必须独占。适用于读多写少的场景。
- 内核实现：
rwlock_t（自旋锁变体）、rw_semaphore（信号量变体）。 - 公平性：写者可能被读者饿死，需要额外策略（如写者优先）。
2.2.5 RCU (Read-Copy-Update)
RCU是一种无锁同步机制，读者几乎不需要加锁，写者通过“替换指针”的方式更新数据，并等待所有读者完成旧数据的访问后再回收。
- 核心思想：延迟回收（deferred reclamation），通过宽限期（grace period）保证安全。
- 读者路径：
rcu_read_lock()/rcu_read_unlock()，开销极低（仅内存屏障）。 - 写者路径：
synchronize_rcu()或call_rcu()。 - 适用场景：路由表、文件系统dentry缓存、网络协议栈。
2.2.6 futex (Fast Userspace Mutex)
futex是用户态与内核态协作的同步机制，核心思想是：无竞争时在用户态完成，只有发生竞争时才陷入内核进行睡眠/唤醒。
- 系统调用：
sys_futex(uaddr, op, val, timeout, uaddr2, val3)。 - 操作：FUTEX_WAIT（等待）、FUTEX_WAKE（唤醒）、FUTEX_REQUEUE（重排队）。
- 地位：futex是用户态pthread互斥锁、条件变量、读写锁的底层基石。
2.3 同步机制对比表
| 特性 | 自旋锁 | 信号量 | 互斥锁 | 读写锁 | RCU | futex |
|---|---|---|---|---|---|---|
| 等待方式 | 忙等待 | 睡眠 | 睡眠 | 忙等待/睡眠 | 无等待（读者） | 用户态+睡眠 |
| 适用上下文 | 中断/原子 | 进程上下文 | 进程上下文 | 进程/中断 | 进程/中断 | 用户态 |
| 临界区大小 | 极短 | 中等 | 中等 | 中等 | 任意（读者） | 任意 |
| 是否可递归 | 否 | 否 | 是（可选） | 否 | 是（读者） | 取决于实现 |
| 优先级继承 | 不支持 | 不支持 | 支持 | 不支持 | 不适用 | 支持（PI-futex） |
| 内核/用户态 | 内核 | 内核 | 内核 | 内核 | 内核 | 用户+内核 |
2.4 同步机制的选择策略
在实际内核开发中，选择合适的同步机制需要权衡以下因素：
- 临界区长度：极短（几行代码）→ 自旋锁；较长 → 互斥锁/信号量。
- 是否允许睡眠：中断上下文 → 只能使用自旋锁或RCU。
- 读写比例：读远多于写 → 读写锁或RCU。
- 实时性要求：需要优先级继承 → 互斥锁（PI mutex）。
- 用户态需求：用户态线程同步 → futex。
经验法则： 优先使用互斥锁（mutex），除非有明确理由使用其他机制。互斥锁在大多数场景下性能良好且语义清晰。仅在中断上下文或对延迟极度敏感时使用自旋锁。
2.5 同步机制的层次关系
下图展示了同步机制在Linux内核中的层次调用关系，从底层硬件到上层抽象。
2.6 futex的独特定位
futex在同步机制中占据特殊地位：它是唯一一个跨越用户态和内核态的同步原语。其他原语（自旋锁、互斥锁等）完全在内核态实现，而futex的设计哲学是：
- 无竞争时：在用户态通过原子操作完成，零系统调用开销。
- 有竞争时：通过系统调用进入内核，进行睡眠/唤醒管理。
- 可组合性：futex可以作为构建块，实现更高级的同步原语（如pthread_mutex、pthread_cond、pthread_rwlock）。
关键洞察： futex的出现解决了传统同步机制的两个痛点：一是纯用户态自旋锁浪费CPU，二是纯内核态锁每次操作都需系统调用。futex通过“快速路径在用户态，慢速路径在内核态”的设计，实现了性能与功能的平衡。
2.7 本章小结
Linux内核提供了丰富的同步机制，每种机制都有其特定的适用场景和性能特征：
- 自旋锁：轻量级，忙等待，适合短临界区。
- 信号量/互斥锁：重量级，睡眠等待，适合长临界区。
- 读写锁：区分读写，适合读多写少。
- RCU：读者无锁，写者替换，适合读极多写极少。
- futex：用户态与内核态协作，是用户态同步的基石。