测试似乎表明样本是正确的但不是。类似的代码很容易最终投入生产，甚至可以完美运行多年。
我们可以从使用-O3 编译示例开始。现在，样本无限期挂起。 （默认是-O0，没有优化/调试一致性，有点类似于让每个变量都变成volatile，which is the reason the test didn't reveal the code as unsafe。）
要找到根本原因，我们必须检查生成的程序集。首先，基于 GCC 4.8.5 -O0 的 x86_64 程序集对应未优化的工作二进制文件：
// Thread B:
// shared = 42;
movq -8(%rbp), %rax
movq (%rax), %rax
movq $42, (%rax)
// Thread A:
// while (shared != 42) {
// }
.L11:
movq -32(%rbp), %rax # Check shared every iteration
cmpq $42, %rax
jne .L11
线程 B 在shared 中执行值42 的简单存储。
线程 A 为每个循环迭代读取 shared，直到比较表明相等。
现在，我们将其与-O3 结果进行比较：
// Thread B:
// shared = 42;
movq 8(%rdi), %rax
movq $42, (%rax)
// Thread A:
// while (shared != 42) {
// }
cmpq $42, (%rsp) # check shared once
je .L87 # and skip the infinite loop or not
.L88:
jmp .L88 # infinite loop
.L87:
与-O3 相关的优化将循环替换为单个比较，如果不相等，则使用无限循环以匹配预期行为。在 GCC 10.2 中，循环被优化了。 （与 C 不同，没有副作用或易失性访问的无限循环在 C++ 中是未定义的行为。）
问题在于编译器及其优化器不知道实现的并发含义。因此，结论需要是shared 不能在线程 A 中更改 - 循环相当于死代码。 （或者换句话说，数据竞争是 UB，并且允许优化器假设程序没有遇到 UB。如果你正在读取一个非原子变量，那一定意味着没有其他人在编写它。这个是允许编译器将负载提升到循环之外的原因，并且类似地接收存储，这对于非共享变量的正常情况是非常有价值的优化。）
解决方案要求我们与编译器沟通shared参与线程间通信。实现这一目标的一种方法可能是volatile。虽然volatile 的实际含义因编译器而异，并且保证（如果有）是特定于编译器的，但普遍的共识是volatile 阻止编译器根据基于寄存器的缓存优化易失性访问。这对于与硬件交互并在并发编程中占有一席之地的低级代码至关重要，尽管由于std::atomic 的引入而呈现下降趋势。
使用volatile int64_t shared，生成的指令变化如下：
// Thread B:
// shared = 42;
movq 24(%rdi), %rax
movq $42, (%rax)
// Thread A:
// while (shared != 42) {
// }
.L87:
movq 8(%rsp), %rax
cmpq $42, %rax
jne .L87
循环不能再被消除，因为它必须假设shared 发生了变化，即使没有代码形式的证据。因此，该示例现在适用于 -O3。
如果volatile 解决了这个问题，你为什么还需要std::atomic？与无锁代码相关的两个方面使std::atomic 必不可少：内存操作原子性和内存顺序。
为了构建加载/存储原子性的案例，我们查看了使用GCC4.8.5 -O3 -m32（32 位版本）为volatile int64_t shared 编译的生成程序集：
// Thread B:
// shared = 42;
movl 4(%esp), %eax
movl 12(%eax), %eax
movl $42, (%eax)
movl $0, 4(%eax)
// Thread A:
// while (shared != 42) {
// }
.L88: # do {
movl 40(%esp), %eax
movl 44(%esp), %edx
xorl $42, %eax
movl %eax, %ecx
orl %edx, %ecx
jne .L88 # } while(shared ^ 42 != 0);
对于 32 位 x86 代码生成，64 位加载和存储通常分为两条指令。对于单线程代码，这不是问题。对于多线程代码，这意味着另一个线程可以看到 64 位内存操作的部分结果，从而为可能不会 100% 导致问题的意外不一致留出空间，但可能会随机发生受周围代码和软件使用模式的影响很大。即使 GCC 选择生成默认保证原子性的指令，这仍然不会影响其他编译器，并且可能不适用于所有支持的平台。
为了防止在所有情况下以及跨所有编译器和支持的平台进行部分加载/存储，可以使用std::atomic。让我们回顾一下std::atomic 如何影响生成的程序集。更新示例：
#include <atomic>
#include <cassert>
#include <cstdint>
#include <thread>
int main()
{
std::atomic<int64_t> shared;
std::thread thread([&shared]() {
shared.store(42, std::memory_order_relaxed);
});
while (shared.load(std::memory_order_relaxed) != 42) {
}
assert(shared.load(std::memory_order_relaxed) == 42);
thread.join();
return 0;
}
基于 GCC 10.2 生成的 32 位程序集（-O3:https://godbolt.org/z/8sPs55nzT）：
// Thread B:
// shared.store(42, std::memory_order_relaxed);
movl $42, %ecx
xorl %ebx, %ebx
subl $8, %esp
movl 16(%esp), %eax
movl 4(%eax), %eax # function arg: pointer to shared
movl %ecx, (%esp)
movl %ebx, 4(%esp)
movq (%esp), %xmm0 # 8-byte reload
movq %xmm0, (%eax) # 8-byte store to shared
addl $8, %esp
// Thread A:
// while (shared.load(std::memory_order_relaxed) != 42) {
// }
.L9: # do {
movq -16(%ebp), %xmm1 # 8-byte load from shared
movq %xmm1, -32(%ebp) # copy to a dummy temporary
movl -32(%ebp), %edx
movl -28(%ebp), %ecx # and scalar reload
movl %edx, %eax
movl %ecx, %edx
xorl $42, %eax
orl %eax, %edx
jne .L9 # } while(shared.load() ^ 42 != 0);
为了保证加载和存储的原子性，编译器发出一个 8 字节的SSE2 movq instruction（到/从 128 位 SSE 寄存器的下半部分）。此外，该程序集显示，即使删除了 volatile，该循环仍然完好无损。
通过在示例中使用std::atomic，可以保证
- std::atomic 加载和存储不受基于寄存器的缓存的影响
- std::atomic 加载和存储不允许观察部分值
C++ 标准根本没有谈论寄存器，但它确实说：
实现应该使原子存储在合理的时间内对原子负载可见。
虽然这为解释留下了空间，但缓存 std::atomic 跨迭代加载，如在我们的示例中触发（没有 volatile 或 atomic）显然是违规行为 - 存储可能永远不会变得可见。当前编译器don't even optimize atomics within one block，就像在同一个迭代中进行 2 次访问。
在 x86 上，自然对齐的加载/存储（地址是加载/存储大小的倍数）为 atomic up to 8 bytes without special instructions。这就是 GCC 能够使用 movq 的原因。
atomic<T> 带有大的T 可能不被硬件直接支持，在这种情况下编译器可以回退to using a mutex。
在某些平台上，较大的T（例如 2 个寄存器的大小）可能需要原子 RMW 操作（如果编译器不简单地回退到锁定），有时会提供比最大效率更大的大小保证原子的纯加载/纯存储。 （例如，在 x86-64、lock cmpxchg16 或 ARM ldrexd/strexd 重试循环上）。单指令原子 RMW（如 x86 使用）internally involve a cache line lock or a bus lock。例如，用于 x86 的旧版本 clang -m32 将使用 lock cmpxchg8b 而不是 movq 用于 8 字节纯加载或纯存储。
上面提到的第二个方面是什么，std::memory_order_relaxed 是什么意思？
编译器和 CPU 都可以重新排序内存操作以优化效率。重新排序的主要约束是所有加载和存储必须看起来已经按照代码给定的顺序（程序顺序）执行。因此，在线程间通信的情况下，必须考虑内存顺序以建立所需的顺序，尽管尝试重新排序。可以为std::atomic 加载和存储指定所需的内存顺序。 std::memory_order_relaxed 不强加任何特定顺序。
互斥原语强制执行特定的内存顺序（获取-释放顺序），以便内存操作保持在锁范围内，并且保证先前锁所有者执行的存储对后续锁所有者可见。因此，使用锁，这里提出的所有方面都可以通过使用锁定工具简单地解决。一旦您摆脱了提供的舒适锁，您就必须注意后果和影响并发正确性的因素。
尽可能明确地说明线程间通信是一个很好的起点，以便编译器了解加载/存储上下文并可以相应地生成代码。只要有可能，preferstd::atomic<T> 和std::memory_order_relaxed（除非场景需要特定的内存顺序）到volatile T（当然还有T）。此外，尽可能不要推出自己的无锁代码，以降低代码复杂性并最大限度地提高正确率。