2. 内核同步机制概览

在并发编程中，保护共享资源免受竞态条件（Race Condition）的破坏是核心挑战。Linux 内核在过去三十年的演进中，针对不同的并发场景（如中断上下文、SMP 多核、读写不对称负载），逐步发展出了一套层次分明的同步机制家族。理解这些机制的演进关系，是掌握性能调优的前提。

2.1 同步机制演进全景图

下图展示了 Linux 内核同步机制从“忙等”到“无锁化”的演进脉络。每种机制都解决了前一代机制的特定痛点。

2.2 五种核心机制对比

下表从 等待行为、上下文限制、并发度、公平性、典型开销 五个维度，对五种机制进行横向对比。

2.3 自旋锁（Spinlock）—— 最基础的忙等锁

自旋锁是最简单的同步原语。当锁被持有时，等待的线程会在一个 tight loop 中不断检查锁状态，直到持有者释放。它 不睡眠，因此可以在中断上下文（Interrupt Context）中使用。

• 适用场景： 临界区极短（通常 < 25 个指令周期），且持有锁的时间远小于一次线程切换开销。
• 变体： spin_lock()（普通）、spin_lock_irqsave()（禁用本地中断）、spin_lock_bh()（禁用下半部）。
• 性能陷阱： 高竞争下 CPU 空转浪费严重，且可能引发优先级反转（Priority Inversion）。

// 自旋锁典型用法（驱动中保护设备寄存器）
DEFINE_SPINLOCK(dev_lock);

void dev_write(struct device *dev, u32 val) {
    unsigned long flags;
    spin_lock_irqsave(&dev_lock, flags);
    writel(val, dev->reg);
    spin_unlock_irqrestore(&dev_lock, flags);
}

2.4 信号量（Semaphore）与互斥锁（Mutex）—— 可睡眠的锁

信号量允许进程在无法获取锁时 睡眠等待，从而避免 CPU 空转。但信号量的计数语义（count > 1 允许多个持有者）容易导致设计复杂。互斥锁是信号量的简化版：强制单一持有者，并引入了 乐观自旋（Optimistic Spinning） 优化——当锁持有者正在运行时，等待者先自旋一小段时间，避免立即睡眠带来的调度开销。

// 互斥锁典型用法（保护复杂数据结构）
struct mutex my_mutex;

void complex_update(struct my_data *data) {
    mutex_lock(&my_mutex);
    // 临界区：可能包含内存分配、文件操作等耗时操作
    data->counter++;
    kfree(data->old_buf);
    data->old_buf = kmalloc(1024, GFP_KERNEL);
    mutex_unlock(&my_mutex);
}

2.5 读写锁（rwlock / rwsem）—— 区分读者与写者

读写锁是同步机制演进的重要里程碑。它 允许多个读者同时进入临界区，但写者必须独占。这完美匹配了“读多写少”的典型负载（如路由表查找、配置读取）。

• rwlock_t（自旋版本）： 读者自旋等待写者释放，适合短临界区；可在中断上下文使用。
• struct rw_semaphore（睡眠版本）： 读者/写者均可睡眠，适合长临界区；只能在进程上下文使用。
• 主要问题： 写者可能被持续的读者流 饿死（Writer Starvation）。在高频读负载下，写者可能永远无法获得锁。

// 读写锁（自旋版本）典型用法
rwlock_t my_rwlock;

void read_path(void) {
    read_lock(&my_rwlock);
    // 多个读者可以同时执行这里
    pr_info("current count: %d\n", shared_counter);
    read_unlock(&my_rwlock);
}

void write_path(void) {
    write_lock(&my_rwlock);
    // 写者独占，等待所有读者释放
    shared_counter++;
    write_unlock(&my_rwlock);
}

2.6 RCU（Read-Copy-Update）—— 无锁读的终极方案

RCU 是 Linux 内核中最先进的同步机制，由 Paul E. McKenney 等人发明。它的核心思想是：读者完全不需要加锁，写者通过“复制-更新-延迟回收”的方式安全修改数据。

RCU 工作流程（三步走）：

1. 复制（Copy）： 写者分配新内存，将旧数据复制到新内存中。
2. 更新（Update）： 写者修改新内存中的数据，然后使用 rcu_assign_pointer() 原子地将全局指针指向新数据。
3. 延迟回收（Deferred Reclaim）： 写者调用 synchronize_rcu() 或 call_rcu()，等待所有正在访问旧数据的读者退出临界区后，再释放旧内存。

// RCU 典型用法（保护链表查找与更新）
struct my_elem {
    int key;
    struct rcu_head rcu;  // 用于延迟回收
    /* ... 其他数据 ... */
};

// 读者路径：完全无锁
void reader_lookup(int key) {
    rcu_read_lock();
    struct my_elem *p = rcu_dereference(global_list_head);
    while (p) {
        if (p->key == key) {
            // 使用 p 的数据
            break;
        }
        p = rcu_dereference(p->next);
    }
    rcu_read_unlock();
}

// 写者路径：复制-更新-延迟回收
void writer_update(int old_key, int new_val) {
    struct my_elem *old, *new;
    
    // 1. 查找旧节点
    old = find_elem(old_key);
    
    // 2. 复制
    new = kmalloc(sizeof(*new), GFP_KERNEL);
    *new = *old;
    new->value = new_val;
    
    // 3. 更新指针（原子操作）
    rcu_assign_pointer(old->next, new->next);
    // 假设我们要替换整个链表头
    rcu_assign_pointer(global_list_head, new);
    
    // 4. 延迟回收旧节点
    synchronize_rcu();  // 阻塞等待所有读者退出
    kfree(old);
}

2.7 演进关系总结：如何选择？

在实际的内核开发中，选择同步机制可以遵循以下决策树：

1. 临界区是否能在中断上下文执行？
   • 是 → 只能用 自旋锁 或 rwlock_t（不可睡眠）。
   • 否 → 进入下一步。
2. 临界区是否极短（< 25 个指令）且竞争低？
   • 是 → 自旋锁 足够。
   • 否 → 进入下一步。
3. 负载是“读多写少”还是“写多读少”？
   • 读多写少（读 > 90%） → 优先考虑 RCU（性能最优），其次 读写锁。
   • 写多读少 → 互斥锁 通常比读写锁更公平、性能更稳定。
4. 是否需要保护复杂的数据结构（如红黑树、哈希表）？
   • 是 → 互斥锁 或 读写锁（RCU 实现复杂，需谨慎）。
   • 否（仅保护简单指针/链表） → RCU 是最佳选择。