CPU缓存一致性与内存模型深度实战：从MESI协议到Linux内核内存屏障的全链路解析

5.3 Read/Write Barrier的变体

Linux还提供了专门的读/写CPU间屏障：

/* 原子操作后加屏障的原子变体 */
#define smp_mb__before_atomic()  smp_mb()
#define smp_mb__after_atomic()   smp_mb()

/* 仅在特定场景下需要的弱屏障 */
#define smp_store_release(ptr, val)                                 \
    do {                                                            \
        compiletime_assert_atomic_type(sizeof(*ptr));               \
        smp_mb(); /* Full barrier before store */                  \
        WRITE_ONCE(*(ptr), (val));                                  \
    } while (0)

#define smp_load_acquire(ptr)                                       \
    ({                                                              \
        typeof(*ptr) ___p1 = READ_ONCE(*(ptr));                     \
        smp_mb(); /* Full barrier after load */                    \
        ___p1;                                                      \
    })

需要注意的是，这里的smp_store_release和smp_load_acquire在Linux内核的早期实现中使用完整smb_mb屏障。在较新版本中（v5.14+），针对ARM64等弱序架构优化为使用STLR/LDAR指令（store-release/load-acquire），在不牺牲正确性的前提下避免完整dmb指令的开销。

5.4 READ_ONCE / WRITE_ONCE

这对宏的作用常被低估。它们不仅仅是赋值——它们还插入编译器屏障（volatile语义），防止编译器对原子访问进行优化（如合并多次读写为一次）：

#define READ_ONCE(x)    (*(const volatile typeof(x) *)&(x))
#define WRITE_ONCE(x, val)  (*(volatile typeof(x) *)&(x) = (val))

漏洞案例：在自旋锁实现中，如果不用READ_ONCE读取锁状态，编译器可能将循环内读取的值缓存在寄存器中，导致持有锁者的写入永远无法被看到——死锁。

六、Spinlock与内存屏障的协同

6.1 为什么Spinlock必须依赖内存屏障？

回顾Spinlock的经典实现（以Ticket Spinlock为例）：

// 获取锁
static inline void spin_lock(spinlock_t *lock)
{
    struct lock_stuff __ticket = spin_ticket_acquire(lock);
    while (lock->serv != __ticket.ticket)
        cpu_relax();
    // 隐式acquire屏障：确保锁内代码不会重排到锁获取之前
}

// 释放锁
static inline void spin_unlock(spinlock_t *lock)
{
    // 隐式release屏障：确保锁内修改在锁释放之前对外可见
    lock->serv++;
}

ARM64上的ticket acquire使用ldaex（load-acquire-exclusive），release使用stex（store-exclusive）。这意味着：

• 获取锁时：acquire语义确保Spinlock保护区域内的所有内存访问不会"提前"到加锁之前执行。不然其他核心可能看到锁还未获取但已经有了保护区内的写操作，导致数据竞争。
• 释放锁时：release语义确保Spinlock保护区域的所有修改在解锁之前已经全局可见。否则其他核心获取锁后看到的可能是旧的缓存内容。

6.2 qspinlock的ARM64内联汇编

Linux内核的ARM64 qspinlock关键路径：

// arch/arm64/include/asm/spinlock.h
static inline void queued_spin_lock(spinlock_t *lock)
{
    u32 tmp;
    struct qspinlock *lock = (struct qspinlock *)lock;
    asm volatile(
        "   prfm    pstl1strm, %3\n"      // 预取锁缓存行
        "1: ldaxr   %w0, %3\n"           // 原子加载（acquire语义）
        "   add     %w0, %w0, #1\n"      // ticket自增
        "   stxr    %w1, %w0, %3\n"      // 原子存
        "   cbnz    %w1, 1b\n"            // 失败则重试
        "   and     %w1, %w0, #0xff\n"   // 取当前服务号
        "   eor     %w1, %w1, %w0, lsr #8\n"
        "   cbnz    %w1, 2f\n"            // 若不等则自旋等待
        "   b       3f\n"
        "2: wfete   #1\n"                 // WFE低功耗等待
        "   ldaxrb  %w1, %2\n"            // 检查服务号更新
        "   eor     %w1, %w1, %w0, lsr #8\n"
        "   cbnz    %w1, 2b\n"
        "3:\n"
        // 隐式屏障：ldaxr保证acquire
        //
        : "=&r" (tmp), "=&r" (tmp2), "+Q" (lock->val)
        : "Q" (lock->val)
        : "memory"); // "memory" clobber是编译器屏障
    );
}

memory clobber告诉编译器：这段汇编代码可能修改任何内存位置，编译器不得跨此语句重排内存访问。这是barrier()和smp_*mb()类宏的核心机制。

七、RCU与内存屏障

7.1 为什么读侧RCU可以零开销？

RCU读侧原语rcu_read_lock()和rcu_read_unlock()在x86_TSO上不生成任何指令——它们只是操作一个每CPU计数器来防止被抢占。为什么可以这样做？

因为x86-TSO已经保证了：

• LoadLoad不会重排（Invalidate Queue不影响同核心内的观察顺序）
• CPU按程序顺序观察到自己的加载

所以读侧只需要保证"不会被抢占导致写侧误判Grace Period结束"，而这个只需要关抢占或标记计数器即可。

但在ARM64弱序模型上，RCU读侧需要额外考虑：如果写侧数据发布使用release语义，读侧必须使用acquire（或consume）语义来获取正确的数据。Linux内核通过rcu_dereference()宏在弱序架构上插入consume/acquire屏障来保证这一点。

7.2 写侧RCU的内存屏障序列

写侧的修改流程（synchronize_rcu()之前）依赖两个关键的屏障：

1. rcu_assign_pointer()：使用release语义（smp_store_release），确保指针发布前的结构体初始化写入必须先于指针本身对读者可见。
2. Grace Period等待：确保所有正在执行的读侧临界区已经退出。synchronize_rcu()使用全屏障保证等待完成后的所有后续代码能看到旧读者已经完全退出。

// 典型的RCU更新序列
new_item = kmalloc(sizeof(*new_item), GFP_KERNEL);
new_item->value = 42;
new_item->next = old_head;

rcu_assign_pointer(head, new_item);  // release: 保证初始化完毕后再发布

synchronize_rcu();                    // 等待所有读者退出

kfree(old_head);                      // 现在可以安全释放旧节点

八、SeqLock与Store-Load重排

8.1 SeqLock的设计目标

SeqLock（顺序锁）解决一个特定场景：读者多、写者少、读侧要求极低开销（追求无等待读），但允许读到脏数据后重试。

它利用了一个关键性质：spinlock保证了写者之间的互斥（写者必须持有锁），所以写侧操作天然有序。

8.2 读写协议

// 写者
write_seqlock(&seq);
data = new_value;      // 修改受保护的数据
write_sequnlock(&seq);

// 读者
unsigned int seq;
do {
    seq = read_seqbegin(&seq);     // 读取序列号（奇数=写者活跃）
    // 临界区：读取数据
    value = data;
} while (read_seqretry(&seq, seq));

读者为什么不加锁？因为读者可以被中断被打断，它只需要检测自己的读操作是否被写者中断过。序列号在写者为奇数、偶数之间切换，读者读到奇数或起始≠重结束说明中间有写入，重试即可。

8.3 SeqLock与内存屏障的精确需求

SeqLock的正确性依赖两个屏障：

• write_seqlock中的屏障：必须保证序列号递增（变奇数）发生在数据修改之前被读者看到。这需要release语义。
• 数据修改后的wmb()：保证data = new_value发生在write_sequnlock的序列号递增（变偶数）之前被读者看到。这需要smp_wmb()。

// ARM64上的seqlock写侧实现
static inline void raw_write_seqcount_begin(seqcount_t *s)
{
    s->sequence++;  // 奇数
    smp_wmb();      // 屏障保证：读者看到奇数必须先看到
                     // 前一次偶数写入的旧数据完整
}

static inline void raw_write_seqcount_end(seqcount_t *s)
{
    smp_wmb();      // 确保：new_data的写入在sequence++之前

                     // （变偶数）对外可见
    s->sequence++;  // 偶数
}

这两个smp_wmb()是绝对关键的。没有第二个wmb，写侧可能先递增了序列号（看起来"写完了"），但new_data还在Store Buffer中，读者读到后认为是新数据但看到的还是旧值。

九、内存屏障性能实测

9.1 屏障指令的周期开销

9.2 无锁队列 vs 加锁队列的性能差异

在典型场景下（高并发读写），无屏障或弱序的无锁队列可获得加锁队列2-5倍的吞吐量。但错误使用屏障（过多地使用mfence或seq_cst）可能使无锁方案反而更慢。

十、实战：正确编写无锁数据结构的黄金法则

10.1 规则一：成对使用release-acquire

数据发布者和消费者必须使用匹配的release-acquire语义。发布者用release标记数据写入完成，消费者用acquire确认看到完整数据。中间不需要seq_cst的强序（除非你是初学者想保守一点）。

10.2 规则二：Store Buffer是你的敌人

如果你在执行两个有因果关系的写入操作，wmb保证它们按序到达其他核心。比如"先设置数据，再设置标志位"——没有wmb，标志位可能先于数据到达其他核心。

10.3 规则三：认清你的架构

在x86-TSO上，StoreStore/LoadLoad/LoadStore重排不会发生。但你的代码可能会跑在任何地方。永远不要假设一种架构的行为会自然扩展到另一种。按需插入屏障，用工具验证。

10.4 规则四：多线程测试不够

内存可见性问题可能在x86上永远不出现（因为x86较强的一致性），但在ARM/RISC-V上反复出现。使用ThreadSanitizer（TSan）在编译期检测竞争：clang -fsanitize=thread your_code.cpp。或者使用Litmus测试工具（如diy工具集）在目标硬件上验证。

10.5 规则五：优先使用高层同步原语

无锁编程错误率极高。先用mutex或spinlock实现功能，性能确认有瓶颈后，确认没有使用底层原子操作更优的方案时再考虑手写屏障。Spinlock、RCU、SeqLock已经精心设计了正确的屏障，覆盖99%的场景。

十一、与前序文章的关联总结

本文与《Linux内核同步机制深度实战：从Spinlock到RCU》构成完整的知识栈：

• 硬件层：MESI/MOESI/MESIF协议保证了缓存层面的最终一致性，但Store Buffer & Invalidate Queue引入了重排的可能。
• 指令层：dmb/dsb/mfence等屏障指令在不同架构下以不同成本恢复顺序保证。
• 编译器层："memory" clobber和volatile语义防止编译器重排。
• 内核抽象层：smp_mb/smp_rmb/smp_wmb + READ_ONCE/WRITE_ONCE + smp_store_release/smp_load_acquire组合成各级同步原语。
• 同步原语层：Spinlock用acquire+release保护临界区；RCU用consume+release实现读侧零开销；SeqLock用smp_wmb保证写侧有序性。

理解这五层，你就能在多核并发编程的任何层级做出正确的技术选型——不再混淆"编译期屏障"和"运行期屏障"，不再盲目使用seq_cst，不再对自旋锁的实现感到神秘。

十二、进阶阅读

• ARM Architecture Reference Manual：D5章（内存模型）和D8章（屏障指令）
• Linux内核文档：Documentation/memory-barriers.txt — 最权威的内存屏障中文档，解释每一个smp_*mb变种
• Paul E. McKenney：Is Parallel Programming Hard, And, If So, What Can You Do About It? — RCU和内存屏障之父亲著
• Preshing on Programming：Jeff Preshing的系列博客（Memory Ordering, Acquire and Release Semantics等）
• Linux内核源码：arch/arm64/include/asm/barrier.h, arch/x86/include/asm/barrier.h, include/asm-generic/barrier.h

至此，我们完成了从CPU晶体管行为到Linux内核同步原语的全链路解析。在下一篇文章中，我们将继续深入Linux内核的中断处理子系统——硬中断、软中断、tasklets和workqueues如何在多核环境下与本文所述的缓存一致性机制交互。