Intel 64和IA-32处理器提供了一个LOCK#信号，它在某些关键的内存操作期间自动被激活，以锁定系统总线或等效链路。当此输出信号被激活时，来自其他处理器或总线代理的对总线控制的请求将被阻塞。软件可以通过在指令前加上LOCK前缀来指定其他需要遵循LOCK语义的场合。
这是来自Intel手册第三卷。
听起来像是对内存的原子操作将直接在内存(RAM)上执行。我有点困惑，因为我在分析汇编代码输出时并没有看到“特别”的地方。
基本上，对于std::atomic<int> X; X.load()生成的汇编输出只是一个正常的mov加载指令。如果我理解得正确，X.store(2)只是mov [somewhere], 2，再加上seq_cst时的mfence, 它负责适当的内存排序，而不是原子性。这就是全部。看来它不会“跳过”cache。
我知道将对齐的整数（例如整型）移动到内存中是原子性的。然而，我感到困惑。
所以，我已经提出了我的疑问，但主要问题是：
CPU如何在内部实现原子操作？
std::atomic<int> X; X.load()只会放置“额外”的 mfence。
编译器不会对 seq_cst 加载进行 MFENCE。
我认为我曾经读到过旧版的 MSVC 会为此发出 MFENCE（可能是为了防止与未加栅栏的 NT 存储器重排序？或者代替存储器操作）。但现在它不再这样做了：我测试了 MSVC 19.00.23026.0。请查看来自this program that dumps its own asm in an online compile&run site 的汇编输出中的 foo 和 bar。
我们不需要在这里设置围栏的原因是x86内存模型禁止同时LoadStore和LoadLoad重排序。早期（非seq_cst）的存储仍然可以延迟到seq_cst加载之后，因此它与在
X.load(mo_acquire);之前使用独立的std::atomic_thread_fence(mo_seq_cst);不同。
这与您认为加载需要如果我理解正确，
X.store(2)只是mov [somewhere], 2
mfence的想法一致; seq_cst加载或存储中的一个需要完整的屏障以防止否则可能发生的StoreLoad重排序。mo_acquire和mo_release在汇编中免费，只需要阻止编译时重新排序，并让我们选择在加载或存储上放置MFENCE完整屏障。）MSVC 的存储汇编与 clang 相同，使用 xchg 执行存储和内存屏障。
原子释放或松散存储可以只使用 mov，它们之间的区别仅在于允许多少编译时重排序。
CPU如何在内部实现原子操作？
正如你在问题中指出的那样，原子性与任何其他操作的排序无关（即memory_order_relaxed）。这只意味着该操作作为单个不可分割的操作（因此得名），而不是多个部分，可以在其他操作的某些部分之前和某些部分之后部分发生。
请记住，原子操作只意味着所有观察者都会看到它已经发生或尚未发生，永远不会部分发生。并没有要求它立即到达主内存（如果很快被覆盖，则根本不需要）。原子地修改或读取L1缓存足以确保任何其他核心或DMA访问将看到对齐的存储器或加载器作为单个原子操作发生。如果这种修改在存储器执行后很长时间才发生（例如由于乱序执行而延迟到存储器退役），那也没关系。
现代CPU（例如具有128位路径的Core2）通常具有原子SSE 128b加载/存储，超出了x86 ISA所保证的范围。但请注意有趣的例外在多插槽Opteron上，可能是由于超级传输。 这证明，仅原子地修改L1缓存不足以为比最窄数据路径更宽的存储提供原子性（在这种情况下，不是L1缓存和执行单元之间的路径）。
对齐很重要：跨越缓存行边界的负载或存储必须进行两次分开访问，这使它非原子性。
{{link1:x86保证了在AMD / Intel上不跨越8B边界的缓存访问是原子的，最多可以访问8个字节。 （或仅适用于Intel P6及更高版本，不跨越缓存行边界）。这意味着在Intel上以原子方式传输整个缓存行（现代CPU上为64B），尽管这比数据路径（Haswell / Skylake上L2和L3之间的32B）更宽。这种原子性在硬件上并非完全“免费”，可能需要一些额外的逻辑来防止一个加载从读取部分传输的缓存行。虽然在旧版本被无效化之后才会发生缓存行转移，因此核心不应在有传输正在进行时从旧副本中读取。 AMD在实践中可以在较小的边界上撕裂，可能是因为使用了与MESI不同的扩展，可以在缓存之间传输脏数据。
对于更广泛的操作数，比如原子地将新数据写入结构体的多个条目中，您需要使用锁来保护它，以便所有访问都尊重该锁。（您可以使用带有重试循环的x86lock cmpxchg16b 来执行原子 16b 存储。请注意，没有办法在没有互斥锁的情况下模拟它。）
原子读取-修改-写入操作是更加困难的
相关：我的回答 Can num++ be atomic for 'int num'? 更详细地讲解了这个问题。
每个核心都有一个私有的 L1 缓存，该缓存与所有其他核心协同（使用 MOESI 协议）。缓存行在各级缓存和主内存之间以从 64 位到 256 位不等的块大小传输。 （这些传输实际上可以在整个缓存行粒度上是原子性的？）
要执行原子 RMW 操作，核心可以将 L1 缓存中的一行保持为已修改状态，在加载和存储之间不接受对受影响的缓存行的任何外部修改，其余系统将看到操作为原子操作。（因此，它是原子的，因为通常的乱序执行规则要求本地线程将自己的代码视为按程序顺序运行。）
它可以通过在原子 RMW 进行时不处理任何缓存一致性消息（或者更复杂的版本，允许其他操作具有更多的并行性）来实现此目的。
未对齐的“lock”操作是一个问题：我们需要其他核心将两个缓存行的修改视为单个原子操作。这可能需要实际存储到DRAM，并采取总线锁定。（AMD的优化手册称，当缓存锁不足时，会发生这种情况。）LOCK#信号（CPU封装/插座的引脚）在旧芯片上被用于带有LOCK前缀的原子操作，现在有了缓存锁。对于更复杂的原子操作，比如.exchange或.fetch_add，你需要使用LOCK前缀或其他类型的原子指令（cmpxchg/8/16？）。
同一手册，系统编程指南部分：
您可以查看Paul E. McKenney的论文和书籍： * 现代微处理器中的内存排序，2007年 * 内存屏障：软件黑客的硬件视角，2010年 * perfbook，"并行编程难吗？如果是，你能做些什么？" 同时， * Intel 64架构内存排序白皮书，2007年。在Pentium 4、Intel Xeon和P6系列处理器中，锁定操作是通过缓存锁或总线锁来处理的。如果内存访问可缓存且仅影响单个缓存行，则会调用缓存锁，并且在操作期间不会锁定系统总线和实际的系统内存位置。
smp_wmb()原语是无操作的[7]。然而，需要编译器指令来防止编译器执行会导致在smp_wmb()原语跨越重排序的优化。smp_mb()和smp_rmb()原语扩展为lock;addl。这个原子指令作为负载和存储的障碍。memory_order_seq_cst比通常意义下的顺序一致性更弱。事实上，他明确表示相反的意见。在C++参考文献中，你截取了句子的其余部分，在它涉及到seq_cst和acq_rel之间的区别之前。 - Peter Cordesmfence？ - Gilgamesz