在多核系统上实现高效同步时，spinlock 是最基础的构建块，但其性能表现高度依赖于底层 CPU 架构的内存模型与缓存一致性协议。x86 与 ARM 在内存序（memory ordering）与缓存一致性上的根本差异，导致相同的 spinlock 实现在两类平台上的行为与开销截然不同。本文将从微架构层面剖析这种差异的本质，并给出架构感知的优化策略。
缓存一致性协议：MESI 状态机与 Cache Line Bouncing
现代多核处理器普遍采用基于失效的缓存一致性协议，其中 MESI（Modified、Exclusive、Shared、Invalid）是最经典的实现。当一个 CPU 核心上的线程 spinlock 变量时，该变量所在的缓存行（cache line，通常 64 字节）在核心间的状态迁移直接决定了总线流量与等待延迟。
在无竞争的场景下，spin 线程首次读取锁变量后，该缓存行会被加载到 L1 缓存并标记为 Shared（S）或 Exclusive（E）状态。由于 MESI 协议的写传播特性，后续的重复读取不会产生总线流量 ——CPU 直接从本地缓存命中。这一特性使得轻度 spin（即锁持有时间极短的情况）能够在不触发大量总线事务的前提下完成。
然而，当锁被另一个核心持有并修改时，缓存行的状态迁移将引发显著的流量开销。持有锁的核心在修改锁变量时，必须将缓存行从 Shared 状态转换为 Modified（M）状态，并向所有其它缓存广播 Invalidate 消息。所有正在 spin 的核心收到 Invalidate 后，必须将本地副本标记为 Invalid（I），随后在下次 spin 循环中发起 BusRd（Bus Read）请求以重新获取最新的缓存行。这一缓存行在多个核心间反复迁移所有权的过程，称为 cache line bouncing，是 spinlock 在高竞争场景下最主要的性能瓶颈。
Linux 内核的 qspinlock（queue-based spinlock）实现正是为缓解这一问题而设计。与简单的 TAS（Test-and-Set）spinlock 不同，qspinlock 采用 MCS 锁的变体，为每个等待者分配独立的队列节点。每个 CPU 核心仅需自旋等待自己的节点，而非竞争同一个锁变量。当锁释放时，仅需将队列头节点的所有权转移给下一个等待者，大幅降低了缓存行的迁移频率。在 NUMA 系统中，进一步的 NUMA-aware qspinlock 优化会尽量让等待者在本地节点上自旋，避免跨节点访问远程内存带来的额外延迟。
内存序差异：x86 TSO 与 ARMv8 弱序模型
缓存一致性协议解决的是「数据是否最新」的问题，而内存序（memory ordering）解决的是「操作何时可见」的问题。x86 与 ARM 在这一维度上的差异，对 spinlock 的正确性与性能都有深远影响。
x86 架构采用 Total Store Order（TSO）内存模型，这是一种相对严格的模型。在 TSO 下，所有 Store 操作在程序顺序上保序，且 Load 操作不能越过之前的 Store。这意味着，在 x86 上编写的无锁代码或 spinlock 代码，即使不加任何内存屏障，通常也能在单线程视角下保持正确性。编译器与 CPU 都不会偷偷将 Store 移到 Load 之后。然而，这种严格性是以硬件复杂度为代价的 ——CPU 必须维护 Store Buffer 并在必要时处理 Store-Load 转发。
ARMv8（以及 RISC-V 的弱序实现）则采用弱内存模型，允许 Load 与 Store 操作在特定条件下重排序。这种灵活性使得 ARM 处理器在功耗与性能优化上拥有更大空间，但也要求软件开发者必须显式使用内存屏障（memory barrier）来确保关键操作的顺序。例如，在 spinlock 的获取路径中，必须使用 LDAR（Load-Acquire）与 STLR（Store-Release）或等效的 barrier 指令来保证：锁变量的读取发生在所有后续操作之前，且对共享数据的写入在释放锁之前对其它核心可见。
这一差异直接影响 spinlock 的实现策略。在 x86 上，简单的 lock xchg 或 lock cmpxchg 指令自带内存语义，无需额外 barrier；而在 ARM 上，必须使用 ldaxr/stxr（Load-Exclusive/Store-Exclusive）序列配合 dmb sy（Data Memory Barrier）或等效的 Acquire/Release 语义。
x86 PAUSE 指令：推测执行惩罚的规避机制
在 x86 架构上，spin-wait 循环的核心开销并非来自缓存一致性流量本身，而是来自 CPU 推测执行（speculative execution）导致的流水线刷新（pipeline flush）。当一个核心在 spin 循环中反复读取锁变量时，CPU 的分支预测器会尝试预测分支走向。一旦预测正确，流水线得以全速执行；但若锁变量的值在两次读取之间被另一个核心修改，CPU 必须回退（replay）所有基于错误推测执行的指令，这会消耗数十个时钟周期。
x86 提供的 PAUSE 指令正是为解决这一问题而设计。PAUSE 向处理器发出信号：当前代码处于 spin-wait 循环中，处理器应当采取以下优化措施。首先，PAUSE 显著降低推测执行的激进程度，使 CPU 更倾向于等待锁变量的实际变化，而非继续沿着错误路径执行。其次，它让出执行单元的占用，允许内存子系统在后台监控缓存行的状态变化，而不是被前端的指令流占满。第三，在支持节能状态的处理器上，PAUSE 可以进入浅层休眠，进一步降低功耗。
从性能数据来看，在高争用场景下，使用 PAUSE 的 spinlock 相比不使用的情况可获得 2 到 5 倍的吞吐提升；在低争用或无争用场景下，虽然单次获取延迟略有增加（因为 PAUSE 会引入数个周期的停顿），但避免了错误推测带来的大额惩罚，综合表现仍然更优。Linux 内核的自旋等待路径（如 cpu_relax()）在 x86 平台上被编译为 _mm_pause() intrinsic，底层即对应 PAUSE 指令。
关于 PAUSE 的参数化配置，现代处理器（如 Intel Skylake 及以后、AMD Zen 系列）对 PAUSE 的行为进行了微调。在一些实现中，PAUSE 的持续时间可以根据处理器的功耗策略动态调整。工程实践中，无需也不应尝试手动控制 PAUSE 的具体周期数 —— 处理器的微代码已经针对典型 spinlock 使用模式进行了优化。开发者只需确保在 spin-wait 循环中正确使用 PAUSE，而非插入 nop 或空循环。
ARM 架构的等待指令：ISB SY 与 WFE/YIELD
ARMv8 提供了多种等待机制，其语义与 x86 PAUSE 有本质区别。hint::spin_loop() 在 AArch64 模式下被编译为 ISB SY（Instruction Synchronization Barrier），而非 PAUSE。
ISB SY 的作用是刷新指令流水线，确保所有在 ISB 之前取指的指令都被废弃，CPU 从 ISB 之后重新开始取指。这一指令主要用于确保内存屏障或系统寄存器变更的可见性，但在 spin-wait 循环中使用它，主要目的是让 CPU 在两次 spin 之间「停顿」一下，避免无意义的空转。与 x86 PAUSE 类似，ISB SY 也能降低功耗并为缓存一致性协议的监控留出时间窗口。
然而，ARM 还提供了更激进的低功耗等待指令：WFE（Wait For Event）与 SEV（Send Event）。WFE 会将处理器核心置于低功耗状态，直到收到一个「事件」—— 可以是另一个核心执行的 SEV 指令，也可以是外部中断或定时器唤醒。理论上，WFE 比 ISB SY 更省电，因为它可以关闭部分时钟域甚至进入更深的休眠状态。
但这里有一个关键的语义陷阱：WFE 的唤醒条件并非仅仅「缓存行状态变化」。在 ARM 的 Event 机制中，WFE 只会在特定条件下唤醒，包括：另一个核心对同一簇（cluster）执行了 SEV、发生了中断、或者发生了定时器溢出。这意味着，如果 spinlock 的释放者与等待者在不同的簇上，或者释放者使用普通内存写入而非 SEV，等待者可能永远不会从 WFE 中醒来，导致死锁。
正因如此，Linux 内核在通用的 spin-wait 路径中并未采用 WFE，而是使用 ISB 的变体或 YIELD 指令。YIELD 显式告知调度器当前线程愿意让出时间片给同核心上的超线程（Hyper-Threading）伙伴，适合在 spin-wait 期间让出计算资源。在 Linux AArch64 的 cpu_relax() 实现中，底层会根据具体的处理器型号选择 yield、isb 或 nop，但绝不会是盲目的 wfe。
架构感知的设计建议
基于以上分析，在跨平台代码中实现高效的 spinlock，需要根据目标架构的内存模型与等待指令特性进行适配。
对于 x86 平台，务必在 spin-wait 循环中使用 _mm_pause() 或等效的 PAUSE 指令。这是获得可接受性能的前提条件。同时，应使用 lock 前缀的原子指令（如 lock xchg、lock cmpxchg）来获取锁，这些指令自带内存屏障语义，无需额外添加 mfence。如果锁的争用可能较高，应考虑使用 MCS 队列锁或 Linux 的 qspinlock 来减少缓存行 bouncing。
对于 ARM/AArch64 平台，必须使用 Load-Acquire/Store-Release 语义的原子指令，如 ldaxr/stxr 序列，或者使用 C++11/C11 的 std::atomic_flag 或 std::atomic<T> 并配合适当的内存序（memory_order_acquire、memory_order_release）。在 spin-wait 循环中，使用编译器提供的 __yield() 或平台特定的 isb sy，但不要假设 wfe 会自动唤醒。在极端功耗敏感的场景下，可以考虑 wfe，但必须确保锁的释放路径会发送 sevl（Send Event to Local）以唤醒所有可能正在 wfe 等待的核心。
在 NUMA 系统上，无论 x86 还是 ARM，都应优先考虑数据局部性。Linux 的 NUMA-aware qspinlock 会尽量让等待者在本地节点上自旋，但应用层代码也应确保锁变量本身分配在合理的内存区域。对于跨节点频繁访问的热点锁，可以考虑为每个节点维护一个本地副本（per-node ticket lock），通过间接层降低远程访问延迟。
监控层面，可以通过 PMU（Performance Monitoring Unit）事件来定量评估 spinlock 的缓存一致性开销。在 x86 上，MACHINE_CLEARS.MEMORY_ORDERING_RETIRED 事件可以统计因内存序违背导致的机器清除次数；BUS_LOCKS 事件可以统计总线锁定的频率。在 ARM 上，相应的事件取决于具体的微架构实现，但通常可以通过 datal1_tlb、l2_cache 相关事件来推断缓存行的迁移频率。
总结来说，spinlock 的高效实现是 CPU 架构知识与工程实践的结合。理解 MESI 协议下缓存行的状态迁移、明确 x86 TSO 与 ARM 弱序模型的差异、正确使用架构特定的等待指令，是构建高性能跨平台同步原语的关键。盲目移植而不考虑这些底层细节，往往会导致在某一平台上性能不佳，甚至在 ARM 平台上出现正确性问题。
参考资料
- Stack Overflow: "What is the purpose of the PAUSE instruction in x86" (2018)
- Stack Overflow: "Overhead of Spin Loop in terms of cache coherence" (2011)
- Stack Overflow: "Why does hint::spin_loop use ISB on aarch64?" (2022)
- Random ASCII: "ARM and Lock-Free Programming" (2020)
- LWN.net: "NUMA-aware qspinlock" (2021)
- Wikipedia: "MESI protocol"