★ FEATURED ARTICLE 内存屏障这玩意儿平时写业务代码根本用不上可一旦碰到多核共享内存或者 DMA 描述符它就成了防止指令重排的最后一道防线。前阵子我调一个双核通信模块就翻过车两个核共用一片共享内存发送方先写“命令”和“数据”最后再写一个 ready 标志接收方轮询到 ready 为 1 之后去读数据结果读回来的命令居然是旧值。而且这种错误不常出现跑一次压力测试可能要几个小时才触发一回排查起来非常折腾。后来我才彻底想明白这里面有两层“重排”在作怪一层是编译器在编译期的重排另一层是 CPU 硬件在运行期的访存重排。内存屏障的意义就是在这两层之间硬生生插进一道关隘让系统在你预期的顺序边界上严格停下来。这篇文章就从多核和 DMA 两个实际场景出发把内存屏障的选型、放置位置和踩坑经验一次说清楚。1. 内存重排的真面目从一次“假死锁”开始1.1 现场还原ready 已经置 1数据却还是旧的当时共享内存的代码大约长这样A 核是生产者B 核是消费者/* A 核 */ shm-opcode OPER_WRITE; shm-payload some_value; shm-ready 1; /* B 核 */ while (shm-ready 0) { /* 轮询等待 */ } do_something(shm-payload);程序逻辑看起来无懈可击先把数据准备好再通知对方。可 B 核真的在 ready 变为 1 之后读出过旧的 payload。更气的是单步调试或者用调试器强制读内存时又一切正常。这种“只在高速运行下出现、一挂调试器就消失”的问题几乎可以断定和重排有关。你看到的 shared 变量在源程序里有固定顺序但编译器不一定会按这个顺序生成机器码即使编译器老实按顺序排了CPU 在执行时也可能偷偷调换访存顺序。最终到达内存系统的顺序和程序里写的顺序可能是两回事。1.2 写缓冲、乱序执行和推测执行重排的三个来源先看写缓冲。现代处理器向内存发起写操作时往往不会让指令“卡”在那里傻等。写地址和数据会先压进一个写缓冲store bufferCPU 认为写操作已经完成继续执行后面的指令而写缓冲里积累的写请求才慢慢落入缓存或内存。问题来了多个写请求在写缓冲里的落盘顺序可能和程序顺序不一致后执行的写反而先被刷出去。再看乱序执行。CPU 内部是有多组执行单元的取到指令后它会判断哪些指令不依赖当前结果提前执行。一般情况下这不会出毛病因为最终提交结果时还要对齐但对多个核观察到的共享内存来说提前执行的读操作可能拿到旧数据等到真正需要时再去缓存里翻逻辑上就乱了。最后还有推测执行。分支还没确定CPU 可能先把某个地址的值读了后面发现猜错了再放弃结果。问题是读操作本身会把数据带上总线或者缓存别的核在时间窗口里看到这个“多余”的访问就会产生外部可见的乱序效果。这三者叠加在一起就是弱内存模型处理器上的日常。不是说 CPU 随便乱来而是它为了性能只保证单核视角下的顺序跨核跨设备的全局顺序需要程序主动去“锁死”。1.3 屏障到底在挡什么不是给缓存“加锁”是规定可见顺序很多人误以为内存屏障是来操作缓存的比如“刷新缓存”或“使缓存失效”。这个理解差得挺远。链表本身并不主动刷 cache它规定的是一个约束屏障之前的存储操作必须对屏障之后的其他观测者“先发生”屏障之后的存取操作不能跑到屏障之前去。打个比方内存屏障就像快递分拣线上的一个强制停顿牌。前面已经贴上单号的包裹必须走完扫描后面新来的包裹才能开始上机。它不是把整条传输带停下来而是保证分拣顺序在你关心的边界上是确定的。多核场景里这个“停顿牌”让 B 核看到 ready 时之前写的 payload 已经被系统按序提交DMA 场景里它让外设看到描述符的 OWN 位时描述符里的 addr、len 都已经写到位。所以排查这类问题的第一原则就是找“发布”边界和“观察”边界在两边都放上对应的屏障语义而不是满代码乱插 dmb。2. 多核场景下屏障指令该怎么选、怎么放2.1 DMB、DSB、ISB一字之差效果完全不同在 ARM 体系里最常见的三个屏障指令是 DMB、DSB 和 ISB。名字很像但语义差别很大放错了通常不会立刻报错而是让你在极端负载下反复踩坑。指令全称核心语义典型用途DMBData Memory Barrier保证屏障前后的数据访问按序执行但不要求前面的访问“完成”多核共享变量、自旋锁、无锁队列DSBData Synchronization Barrier等屏障前的所有数据访问真正完成、到达终点DMA 启动前的 cache clean 等待、中断使能前的内存可见性ISBInstruction Synchronization Barrier清空流水线、同步指令上下文修改代码后、修改 MMU/缓存控制寄存器后字面上看DMB 更像“排序约定”它要求后续访问不能比前导访问更早被观测到DSB 更严格它不但排序还要等到前面的写操作真正完成并对外可见。写设备寄存器、清理 cache 这类操作多数时候用 DSB 才稳妥因为你要的是“已经做完了”而不是“顺序没问题但还没完成”。RISC-V 上对应的则是 fence 系列比如fence rw,rw表示在 fence 前的读写操作对 fence 后的读写操作排序。如果你碰过两种架构会发现核心思想一致只是表达粒度不同。2.2 一个最典型的应用自旋锁的 acquire/release多核裸机或者 RTOS 里的自旋锁本质上就是一对 release/acquire 操作。持有者释放锁之前所有对共享数据的修改必须先让锁的释放操作“后发生”等待者拿到锁之后对共享数据的读取才能开始。没有这个配对就算锁被原子地换来换去保护的数据照样可能读脏。现代编译器支持内建原子操作可以直接表达语义static inline void lock_acquire(volatile unsigned int *lk) { while (__atomic_exchange_n(lk, 1, __ATOMIC_ACQUIRE)) { /* 忙等待 */ } } static inline void lock_release(volatile unsigned int *lk) { __atomic_store_n(lk, 0, __ATOMIC_RELEASE); }__ATOMIC_ACQUIRE在 ARMv8 上会被编译器翻译成带 acquire 语义的加载指令等价于在成功获得锁之后先做一次屏障__ATOMIC_RELEASE对应 store-release保证释放锁之前的那些写操作一定排在锁标志清 0 之前。在 x86 上编译器可能只生成普通指令因为 x86 的存储模型本身够强但这不代表代码可以随意换成普通赋值。实际项目里我更建议直接用编译器内建原子操作而不是手写dmb。理由很简单编译器内建原子操作把编译期屏障和 CPU 屏障都管住了手写 dmb 还需要额外保证编译器不去把变量读写挪到 dmb 前后极其容易漏。2.3 无锁单生产者单消费者队列屏障放在哪里自旋锁适合临界区不长的情况而如果你写的是高频数据通道往往会用无锁 SPSC 队列。这类队列的防线就在“发布位置”和“获取位置”/* 生产者填好数据再更新尾指针 */ ring-buf[ring-tail].value v; __atomic_store_n(ring-tail, ring-tail 1, __ATOMIC_RELEASE); /* 消费者先读尾指针再读数据 */ while (__atomic_load_n(ring-tail, __ATOMIC_ACQUIRE) ring-head) { /* 等待新数据 */ } v ring-buf[ring-head].value; ring-head;这里的关键是 tail 指针的 release 语义。生产者对 buf 数据的写必须保证在消费者看到 tail 更新之前提交消费者的 acquire 语义则保证看到新 tail 后读取 buf 数据时不会拿到旧值。两件事合起来才形成“数据先就绪、通知后到达”的完整因果链。我见过有人图省事把 release/acquire 换成普通 volatile 读写。在被测场景下可能是好的因为 volatile 只会阻止编译器把访问合并掉它既不能阻止编译器跨变量重排也不能约束 CPU 乱序迟早会在大压力下翻车。2.4 除了锁还别忘了处理器间中断另一种常见的多核同步路径是 SMGI/IPI。核 A 写好共享数据后发一个处理器间中断把核 B 从等待中唤醒来读取。这里容易误以为中断本身自带屏障。实际上中断到达只是把 CPU 的执行流切换了它并不保证核 B 能看到核 A 在中断之前写的所有数据。稳妥做法是在核 A 发中断前做 release 操作在核 B 的中断处理函数开头做 acquire 操作和 2.3 的队列套路完全一样。ARM 的 DSB 在这里有个重要作用等共享内存的写操作真正完成再触发中断请求。如果只是普通写标志加 IPI可能出现中断先到、数据还没落盘的情况处理函数读到的就是旧数据。这个细节在很多 SoC 手册上写得非常隐晦只有在压力测试中才会露出马脚。3. DMA 侧的顺序问题描述符链与缓存操作的另一半3.1 为什么 DMA 眼中的内存顺序和 CPU 不一样DMA 是总线主设备它本身不会像 CPU 那样乱序执行但它的“观察窗口”来自总线上实际流动的内存事务。CPU 往内存里写数据时如果写操作还躺在缓存或者写缓冲里没出去DMA 从另一端读到的自然就是旧数据。换句话说CPU 在源程序里写好了所有内容不代表 DMA 能看到所有内容中间隔着缓存一致性和访存顺序两道坎。很多人在多核场景里养成了“跑不过就用 dmb 顶一下”的习惯跑到 DMA 场景发现还是出错。原因往往不是 dmb 加得不够而是忘了DMA 要么从一致性总线端口读数据要么直接面对物理内存如果数据还在 CPU 的 cache 里没有回写放多少个内存屏障都无济于事。屏障保证顺序缓存维护保证数据到底在不在物理内存里两者是配合关系不是替代关系。3.2 描述符链一个经典的就绪标志翻转问题网络控制器、存储控制器、显示控制器这些外设通常使用 DMA 描述符链。驱动把地址、长度、标志位写进描述符结构体最后把标志位写成 OWN 交给硬件。这里的标志位写入就是“发布边界”硬件看到 OWN 之后就可以去读 addr 和 len 了。struct hw_desc { uint32_t addr; uint32_t len; uint32_t flags; /* 最高位是 OWN置 1 表示可由 DMA 接管 */ }; desc-addr (uint32_t)buf; desc-len length; dma_wmb(); desc-flags OWN_MASK;dma_wmb()在 Linux 内核里是专门给 DMA 场景准备的写屏障等价于架构相关的高保证写屏障。它保证 addr、len 的写在 flags 的写被 DMA 观察到之前已经就绪。如果把它去掉这两个字段的写可能还停留在 CPU 缓存或者写缓冲里DMA 已经看到 OWN 为 1 开始搬运轻则数据错位重则直接读到了一个非法地址导致总线错误。DMA 完成后同样有顺序问题。硬件写完状态位和数据之后如果 CPU 侧的中断处理函数直接去读数据在没有 acquire 语义的情况下可能先看到状态位 DONE然后读数据时拿到旧缓存。所以状态读取和数据读取之间必须安排一个 acquire 风格的屏障或者用统一的原子读取得语义来读状态位。3.3 缓存一致性与屏障的配合clean 之后要跟着 DSB如果 DMA 访问的内存区域是非一致性的驱动就要负责缓存维护。对 CPU 写往 DMA 的方向通常流程是/* 1. CPU 写完数据 */ write_data_to_buffer(buf, len); /* 2. 把 CPU cache 中的数据回写到内存 */ clean_dcache_range(buf, len); /* 3. 关键用 DSB 等待 cache clean 真正完成 */ dsb(); /* 4. 填充描述符释放给 DMA */ desc-addr buf; desc-len len; dma_wmb(); desc-flags OWN_MASK;第 3 步特别容易被忽略。clean_dcache_range()往往只是往 cache 维护引擎里提交了操作CPU 并不会天然等待它完成。如果用 DMB 而不是 DSB可能 DMB 保证了“后续指令不会乱序”但 cache clean 操作还没跑到总线DMA 就已经看到 OWN 启动搬运。DSB 在这里不是可有可无的强化而是必须等到前序缓存维护操作真正生效的唯一手段。反方向DMA 写完数据后CPU 读取之前要先做 invalidate并且同样要用 DSB 等 invalidate 完成。否则 CPU 可能读到执行 invalidation 之前缓存中的旧行造成“数据明明被 DMA 更新了CPU 却读不到新内容”的假象。这种问题用示波器逻辑分析仪都很难抓只能通过系统化检查缓存维护屏障链来定位。3.4 不要把 DMA 控制器当成另一个“核”有些工程师会问既然 DMA 不会重排那我只做 cache clean不插内存屏障行不行答案是不行。CPU 侧对描述符字段的多次写操作本身就是弱序的cache clean 保证的是“某个地址上的数据写回了内存”但没办法保证描述符中 addr 的写一定排在 flags 的写前面。只有内存屏障才能同时约束 CPU 侧多个访存操作之间的先后关系。所以 DMA 场景的完整防线是两层一层是 cache 维护解决“数据到底有没有到内存”的问题一层是内存屏障解决“多个访存操作到达内存的顺序对不对”的问题。两件事缺一不可。这也是标题里说“最后一道防线”的原因——前面一切数据准备都做好了屏障是防止顺序破功的那道闸门。4. 编译屏障和 CPU 屏障不能二选一4.1 volatile 不是屏障它只保证“不被优化掉”裸机圈非常流行volatile尤其是做寄存器访问和中断共享变量时。但把 volatile 当内存屏障用是一个很危险的误区。volatile 告诉编译器每次访问都要真的去内存里取不要合并、不要删除、不要放到寄存器里缓存。它并不保证不同 volatile 变量之间的访问顺序也不提供任何 CPU 层面的排序语义。看这个例子int val; volatile int flag; void producer(void) { val 42; flag 1; }编译器完全有理由先放flag 1再放val 42因为对编译器来说这两个普通写操作之间没有可观察的依赖关系只要单线程语义没被破坏它就可以重排。到了 CPU 层面即便编译器不重排弱序 CPU 也可能把两个 store 调换提交顺序。最后效果一样flag 先可见val 后出来。4.2 用 barrier() 管住编译器再谈硬件屏障Linux 内核和很多嵌入式项目里都有这个宏#define barrier() asm volatile( ::: memory)它的作用是让编译器认为内存已经被“弄脏”了指令不能越过这一行任意重排。但它只作用于编译期编译后的二进制指令没有包含任何 CPU 排序指令所以它管不住硬件乱序。正确姿势是“编译屏障 CPU 屏障”两步走。裸机下可以这样组合#define cpu_mb() asm volatile(dmb sy ::: memory) #define WRITE_ONCE(p, v) (*(volatile typeof(p) *)((p)) (v)) val 42; compile_barrier(); WRITE_ONCE(flag, 1);写的时候用编译屏障隔开不同变量的写顺序同时还要在发布点上提供 CPU 屏障让硬件层面也认可这个顺序。用 C11 的原子操作可以少操心这些底细编译器会按 memory_order 自动生成对应的指令。4.3 用语言级别的内存模型替代手写 dmb如果项目编译器支持 C11 原子库我强烈建议用memory_order_acquire/release而不是手工管理 dmb 和 barrier。因为手写的漏掉一半的概率实在太高而语言级别的语义会被编译器翻译成正确的“编译屏障 硬件屏障”组合。#include stdatomic.h atomic_int ready ATOMIC_VAR_INIT(0); int val; void producer(void) { val 42; atomic_store_explicit(ready, 1, memory_order_release); } void consumer(void) { while (!atomic_load_explicit(ready, memory_order_acquire)) { /* 等待 */ } use(val); }在 ARMv8 上release store 大概率映射到stlracquire load 映射到ldar它们天然包含单向排序语义。换到 x86 上可能只是编译期保住顺序的普通 store/load因为 x86 硬件已经足够强。这是把可移植性交给语言内存模型带来的最大好处每个架构都能得到该架构的“最低充分防线”既不会过度使用最重的 DB也不会漏掉必要的 DSB。5. 不同架构的落地差异跟踩坑记录5.1 别拿 x86 的经验直接套在 ARM 上我在项目里经常做 x86 和 ARM 两边的代码移植最深的感触是x86 的强存储模型把很多重排问题藏在了硬件后面。架构存储模型常用的屏障/原子能力要注意的坑ARMv7-A弱排序DMB/DSB/ISBLDREX/STREX必须显式处理shareability 域要看清ARMv8-A弱排序DMB/DSBLDAR/STLRacquire/release 指令原生支持用起来最顺手RISC-V弱排序fence rw,rw原子指令 aq/rlfence 粒度可裁剪但别把“标签”当成“指令”x86TSO相对强lock 前缀mfence/sfence/lfencestore-load 顺序仍可能重排别完全裸奔x86 上普通写写操作基本不被硬件重排所以很多自旋锁在 x86 上“感觉不加 dmb 也能跑”。一旦移植到 ARM 平台同样的代码可能立刻出现偶发异常。反过来讲ARM 上习惯性到处插 DSB 的代码移植到 x86性能又有损失。最好的办法是让代码表达“语义”而不是表达“某个架构的指令名字”。5.2 shareability 域与屏障范围ARM 的 DMB/DSB 还可以带后缀比如dmb ish、dmb osh、dmb nsh。它们对应的是内部共享域、外部共享域、非共享域。两个核心都在同一个 cluster 里ish可能足够了如果 DMA 或者另一个 cluster 里的核也要感知却只用了 ish那排序约束的范围可能覆盖不到。选范围时不能想当然要看 SoC 手册里 DMA 挂在哪个一致性端口、几个 cluster 是否共享同一个一致性网络。项目里最稳妥的做法是先用系统默认的dmb sy或者dmb ish跑通功能再按性能测试结果决定是否收窄。收窄后一定要配合文档核查否则表面测不出问题换一颗芯片或者改一个主频就可能爆发。5.3 我的最小屏障配置清单这几年排查多核和 DMA 问题我总结出了一套很朴素的检查清单每次遇到可疑的偶发数据错误就拿它逐条过每一次要让“别的核/外设看到我写的值”先问自己这个发布点有没有 release 语义数据写入和发布之间有没有编译屏障或硬件屏障每次依据“别人写的标志”去读共享数据第一反应应该是 acquire而不是直接读 volatile。acquire 保证标志可见后后续读操作不被提前执行。DMA 启动前如果目标缓冲区需要 cache cleanclean 之后一定要 DSB 等待完成不能只靠 DMB 排序。描述符的 OWN 位是标准发布边界置 OWN 前必须完成描述符字段的写屏障最好用 dma_wmb 或等效语义。写代码时优先用 C11 原子操作、内核的 READ_ONCE/WRITE_ONCE 等包装宏它们比手写 dmbbarrier 更不容易漏。我刚解决双核通信问题时排查手段也是这么一步步收紧的。先用 trace 工具观察共享数据的访问序列怀疑是重排后加上 release/acquire 原子操作问题消失接着把 cache clean 和 DSB 补到 DMA 方向第二步的偶发脏数据也消失了。内存屏障确实不是常规开发里的高频主题可一旦被它咬上那种“跑了几小时挂一次、挂了又复现不了”的感觉足以让人把它刻进骨子里。
阅读完成 · 觉得有帮助？
