Volatile与内存屏障：能否用内存屏障实现Volatile的内存读写保证？

核心问题 #

是否可以用内存屏障实现volatile变量的相同「保证」（始终读写内存而非寄存器）？仅在一个线程中写入变量，在另一个线程中读取其值。以下代码是否等价？

#define rmb() __sync_synchronize()
#define wmb() __sync_synchronize()
static volatile int a;
static int b;

// 线程1调用
static void writer(void)
{
    ...
    a = 1;
    ...
    b = 1;
    wmb();
}

// 线程2调用
static void reader(void)
{
    ...
    while (a != 1)
        ;
    // 执行操作
    ...
    while (b != 1)
        rmb();
    // 执行操作
}

补充疑问 #

我了解volatile不保证原子性、可见性或顺序性。内存屏障除了顺序性之外还能提供其他保障吗？比如可见性？除了C11的_Atomic或GCC/Clang原子内置函数，还有其他方式保证可见性吗？

问题解答 #

1. 内存屏障能否替代volatile的「内存读写保证」？

在单写多读的场景下，可以用内存屏障配合普通变量模拟volatile“绕过寄存器缓存、直接读写内存”的行为，但两者语义本质不同：

• volatile是编译期约束：告诉编译器不能对该变量做寄存器缓存优化，每次读写都必须生成直接访问内存的指令，但它不约束CPU的重排序或缓存一致性行为。
• 内存屏障是硬件/CPU层面的约束：不仅能阻止CPU的指令重排序，还会强制刷新CPU缓存（写屏障）或使CPU重新从内存加载数据（读屏障），从而保证可见性。

2. 给出的代码是否等价？

不等价，核心问题有两点：

• 变量a被声明为volatile，但writer线程中对a的写入未配合写屏障，reader线程的while(a !=1)循环虽因volatile每次读内存，但CPU可能仍持有旧缓存值，理论上存在可见性延迟（实际x86平台因缓存一致性协议可能自动同步，但这不是标准保证）。
• reader线程中while(b !=1)循环的rmb()位置错误：每次循环仅执行内存屏障，却没有重新读取b的操作——内存屏障仅保证后续读操作从内存加载，但必须触发读动作才行。正确写法应在循环内先执行rmb()再读取b，或把b的读取放在屏障之后。

3. 内存屏障的额外保障：可见性

是的，内存屏障除了顺序性，确实能提供可见性保障：

• 写屏障（wmb）：会将CPU写缓冲区的数据刷新到内存，同时使其他CPU的对应缓存行失效，确保后续其他线程能读到最新值。
• 读屏障（rmb）：会使CPU丢弃缓存中的旧数据，强制从内存重新加载，确保读到的是最新值。

4. 除C11 _Atomic和GCC/Clang原子内置函数外的可见性保证方式

还有这些可行方案：

• 平台特定内存屏障指令：比如x86的mfence/lfence/sfence、ARM的dmb/dsb等，通过内联汇编直接调用。
• 互斥锁（mutex）：加锁、解锁操作本身隐含内存屏障语义，进入临界区时会刷新缓存，退出时会同步写操作，保证临界区内变量的可见性。
• 信号量、条件变量等同步原语：这类同步机制底层都包含内存屏障，同样能保证跨线程的变量可见性。

内容的提问来源于stack exchange，提问作者Markus Fuchs