一、背景CPU 多级缓存架构为了读者在阅读后序章节时有更清晰、更形象的认知这里放上现代 CPU 缓存的典型结构。一图胜千言不多赘述仅陈述以下要点一颗 CPU往往有多个核心core。同一时刻每个 core 上都可以运行一个线程thread。为了追求更高的效率编译器 / CPU 可能重排某些指令把后面的提前执行。CPU 增加了多级缓存。这使得某些情况下某个线程看到的数据可能是非预期的进而导致程序出现逻辑错误。当然这并不是说编译器或者 CPU 的设计有缺陷而是一种平衡与妥协为了效率 编译器 / CPU 会适度“放宽政策”不做过于严苛的约束和检查这在多数情况下是安全的为了正确性在并发编程时开发者需要更加精细的干预。 点击查看图片二、概念辨析1. 缓存一致性Cache Coherence层次纯硬件机制在 CPU 内部固化。解决的问题同一个内存地址单一变量在多个CPU 核心的本地缓存L1/L2 Cache中如何同步。即一个核心的写入如何让其它核心感知核心0的L1缓存: [addr X] 1 ← 我刚写入核心1的L1缓存: [addr X] 0 ← 这里还是旧值怎么同步机制MESI、MOESI、MESIF协议状态机。注意这些缓存一致性协议是固化在CPU内部的纯硬件实现。M (Modified) - 该 cache line 仅存在当前 cache 中与内存不一致dirty其他 CPU core 缓存无效E (Exclusive) - 该 cache line 仅存在当前 cache 中与内存一致cleanS (Shared) - 该 cache line 被多核共享且与内存一致I (Invalid) - 该 cache line 已失效需重新加载关键特性单地址/变量最终一致但不保证何时能看到因为有 store buffer。不保证多个地址之间的对外可见顺序核心1可能先看到先看到修改后的变量A后看到修改后的变量B核心2可能正好赶过来。对程序员完全透明你不需要也不能直接操控它。通俗理解它是底层的“群消息同步机制”保证群里所有人看到的单条消息内容是一致的。2. 内存一致性模型Memory Consistency Model层次硬件架构规范层由 CPU 架构决定不同类型的 CPU 不一样。解决的问题多个地址上的读写操作从其它核心观察时顺序会不会乱允许哪些重排这才是真正决定多线程程序正确性游戏规则的模型允许的重排模型 Load-Load Load-Store Store-Store Store-Load───────────────────────────────────────────────────────────────────────────────────────Sequential Consistency (SC) × × × ×Total Store Order (TSO) × × × ✓ ← 只允许这个Relaxed / Weak Consistency ✓ ✓ ✓ ✓不同架构的选择x86/x64TSOTotal Store Order——接近最强只允许 Store→Load 重排。ARM非常宽松weakly ordered几乎允许所有重排。POWER类似 ARM甚至更宽松。缓存一致性 vs 内存一致性模型的区别缓存一致性回答一个地址的写入最终会传播吗答会最终所有核心一定能看到一致结果内存一致性模型回答多个地址的操作以什么顺序传播是否允许后操作的先被看到通俗理解你发了消息 A又发了消息 B。内存一致性模型决定了群里其他人有没有可能先看到 B后看到 A。3. 内存屏障Memory Barrier / Fence层次硬件指令 编译器指令解决的问题在代码的特定位置强制约束重排序边界。是程序员/编译器用来干预“内存一致性”的物理武器。类型Load Barrier屏障前的所有 load 操作必须在屏障后的任何 load 操作开始之前全局完成对其他处理器可见。Store Barrier屏障前的所有 store 操作必须在屏障后的任何 store 操作开始之前全局完成从 Store Buffer 刷新到 L1 Cache并对其他处理器可见Full Barrier 屏障前的所有读和写操作必须在屏障后的任何读和写操作开始之前全局完成。具体指令x86:LFENCE → Load BarrierSFENCE → Store BarrierMFENCE → Full Barrier最常用LOCK前缀 → 隐含 Full BarrierARM:DMB ISH → Full Barrier数据内存屏障DSB ISH → 更强的同步屏障ISB → 指令同步屏障刷流水线两种屏障注意区分// 编译器屏障只防止编译器重排CPU不受限asm volatile( ::: memory); // GCC_ReadWriteBarrier(); // MSVC// 硬件屏障同时防止编译器重排 CPU重排asm volatile(mfence ::: memory); // x86 Full Barrier4. 内存序Memory Order层次C 编程语言层C11 引入。本质是对内存屏障的高级抽象让程序员用语义而非汇编指令来表达需求。机制你写下memory_order编译器会根据当前的 CPU 架构x86 还是 ARM自动帮你翻译成对应架构的内存屏障指令Memory Barrier。六个级别relaxed → 只保证原子性不产生任何屏障acquire → Load 时用屏障后的操作不能重排到此 Load 之前release → Store 时用屏障前的操作不能重排到此 Store 之后acq_rel → 用于 RMW同时具备 acquire release 语义consume → acquire 的弱化版实践中几乎不用seq_cst → 最强全局顺序一致等价于 Full Barrier编译器如何翻译C memory_order x86 生成 ARM 生成─────────────────────────────────────────────────────relaxed load → MOV LDRrelaxed store → MOV STRacquire load → MOV LDARrelease store → MOV STLRseq_cst store → MOV MFENCE STLR DMBseq_cst load → MOV LDARx86 上 acquire/release 不需要额外指令因为 TSO 已经提供了大部分保证ARM 上需要专用指令。5. 四者关系 点击查看图片它们的依赖关系缓存一致性硬件底座没有它写入根本无法传播其他一切无从谈起。内存一致性模型硬件架构契约与规则定义了默认允许什么、禁止什么。内存屏障硬件指令是工具和手段当默认规则不够用时用它来强化约束。内存序是软件层高级抽象C 程序员通过它告诉编译器需要什么保证三、内存序/内存屏障的作用范围作用1防止当前线程内的指令重排编译器 CPU// 没有屏障编译器和CPU可能重排这两条指令data 42; // 可能被移到 flag store 之后flag true;// 有 release 屏障data 42 一定在 flag true 之前完成data 42;flag.store(true, memory_order_release); // 屏障作用2控制跨线程的可见性时序通过控制“store 何时变得全局可见”和“load 何时看到最新值”来影响其他线程的观察结果。内存屏障的物理效果以 x86 TSO 为例CPU Core 0: Store Buffer Cache共享─────────────────────────────────────────────────────────────store data 42 → 进入 Store Buffer → [等待提交]store flag true → 进入 Store Buffer → [等待提交]MFENCE → 强制刷新 Store Buffer → data42, flagtrue 提交到 CacheCPU Core 1: Cache共享─────────────────────────────────────────────────────────────load flag ← 从 Cache 读必须看到 flagtrue 后才能继续MFENCE / acquire ← 确保后续 load 看到最新 Cache 状态load data ← 从 Cache 读 → 一定是 42关键点内存屏障强制刷新 Store Buffer让 store 提交到 Cache对其他核心可见缓存一致性协议MESI负责在 Cache 之间传播这个更新acquire load 确保从 Cache 读时看到最新状态不使用过期的缓存行所以防重排编译器/CPU内部 强制可见性跨线程↑ ↑同一个机制两种效果不可分割四、Store-Load 重排1. 原因根本原因Store Buffer写缓冲区当 CPU 执行写操作Store时如果直接写入L1 Cache由于多核之间的“缓存一致性协议如MESI”CPU 必须等待其他核心确认并作废它们对应的缓存行这个等待过程比较漫长CPU 视角。为了不阻塞 CPU核心会先把数据写到 Store Buffer 中然后继续执行后续指令。现代 CPU 架构CPU Core↓ store[Store Buffer] ← store 先写这里速度快不用等Cache响应↓ 异步刷新[L1 Cache]↓[L2 Cache]↓[LLC / 内存]问题场景Dekker 互斥算法的经典失败案例初始值X 0, Y 0Thread 1: Thread 2:store X 1 store Y 1load R1 Y load R2 X期望R11 或 R21 至少有一个成立实际R10 且 R20 竟然可能发生x86上也会时序解析Time →Thread 1: store X1 → [Store Buffer] ← 还没提交到 CacheThread 1: load Y0 ← 从 Cache 读Y 的 store 还在 Thread2 的 Store Buffer 里Thread 2: store Y1 → [Store Buffer] ← 还没提交到 CacheThread 2: load X0 ← 从 Cache 读X 的 store 还在 Thread1 的 Store Buffer 里// 结果R10, R20。两个 store 都消失了Store-Load 重排的本质不是 CPU 真的调换了顺序而是 store 在 store buffer 里异步等待而 load 已经直接去 cache 读了。效果上等价于 load 跑到了 store 之前。Store-Load 重排的理解从外部观察者其它 CPU core的视角看load 跑到 store 的前头了。因为从外部观察者的立场来看store完成的标志是“你得让我看见”。现在在没有让我看到你写的值的情况下你先执行了后面的 load 指令那对我来说你就是先读后写了。注意x86/TSO 只允许 Store→Load 重排其他三种Load-Load, Load-Store, Store-Storex86 不允许。ARM 四种都允许。2. 解决方案方法1在 store 和 load 之间插入 Full Barrier// x86asm volatile(mfence ::: memory);// C 标准方式std::atomic_thread_fence(std::memory_order_seq_cst);Thread 1:store X 1MFENCE ← 强制刷新 Store BufferX1 提交到 Cacheload R1 Y ← 此时 Y 的最新值一定可见Thread 2:store Y 1MFENCEload R2 X ← 此时 X1 一定可见方法2使用 seq_cst 原子操作std::atomicint X{0}, Y{0};// Thread 1X.store(1, std::memory_order_seq_cst); // 含隐式 Full Barrierint r1 Y.load(std::memory_order_seq_cst);// Thread 2Y.store(1, std::memory_order_seq_cst);int r2 X.load(std::memory_order_seq_cst);// 保证r11 或 r21 至少一个成立