32 位读取时 Compiler Barrier() 的用途

Question

当我在 64 位项目的 VS2017 上分配 atomic_long 类型时，我一直在逐步完成所涉及的函数调用。我特别想看看当我将atomic_long 复制到一个非原子变量时会发生什么，以及它周围是否有任何锁定。

atomic_long ll = 10;
long t2 = ll;

最终以这个调用结束（我删除了一些 ifdefed out 的代码）

inline _Uint4_t _Load_seq_cst_4(volatile _Uint4_t *_Tgt)
    {   /* load from *_Tgt atomically with
            sequentially consistent memory order */
    _Uint4_t _Value;

    _Value = *_Tgt;
    _Compiler_barrier();

    return (_Value);
    }

现在，我读到 from MSDN 说 32 位值的普通读取将是原子的：

对正确对齐的 32 位变量的简单读写是 原子操作。

...这就解释了为什么没有Interlocked 函数用于阅读；只有那些用于更改/比较的。我想知道_Compiler_barrier() 位在做什么。这是#defined

__MACHINE(void _ReadWriteBarrier(void))

...我又在MSDN 上发现了这个

限制可以重新排序内存访问的编译器优化 跨越通话点。

但我不明白，因为除了return 调用之外没有其他内存访问；肯定编译器不会将赋值移到下面吗？

有人可以澄清这个障碍的目的吗？

Answer 1

_Load_seq_cst_4 是一个inline 函数。编译器屏障用于阻止与内联到的调用函数中的后续代码重新排序。

例如，考虑阅读SeqLock。 （过度简化自this actual implementation）。

#include <atomic>
atomic<unsigned> sequence;
atomic_long  value;

long seqlock_try_read() {
    // this would normally be the body of a retry-loop;
    unsigned seq1 = sequence;
    long tmpval = value;
    unsigned seq2 = sequence;

    if (seq1 == seq2 && (seq1 & 1 == 0)
        return tmpval;
    else
        // writer was modifying it, we should retry the loop
}

如果我们不阻止编译时重新排序，编译器可以将 sequence 的两个读取合并到一个访问中，就像这样

    long tmpval = value;
    unsigned seq1 = sequence;
    unsigned seq2 = sequence;

这会破坏锁定机制（作者在修改数据之前增加一次sequence，然后在完成后再次增加一次）。阅读器是完全无锁的，但它不是“无锁”算法，因为如果作者在更新过程中卡住，阅读器将无法阅读任何内容。

屏障内每个load函数在内联后阻止与其他事物重新排序。

（C++11 内存模型很弱，但是 x86 内存模型很强大，只允许 StoreLoad 重新排序。阻塞编译时重新排序和稍后的加载/存储足以给你一个获取/顺序一致性加载在运行时。x86: Are memory barriers needed here?)

---

顺便说一句，一个更好的例子可能是在看到atomic 标志中的某个值后读取/写入一些非atomic 变量。 MSVC 可能已经避免了原子访问的重新排序或合并，并且在 seqlock 中，受保护的数据也必须是 atomic。

Why don't compilers merge redundant std::atomic writes?