Why does this `std::atomic_thread_fence` work的后续问题
由于虚拟互锁操作优于_mm_mfence，并且有很多方法可以实现它，哪个互锁操作以及应使用哪些数据？
假设使用一个内联程序集，它不了解周围的上下文，但是可以告诉编译器将其注册为Clobbers。
最佳答案
现在的简短答案，而无需过多说明原因。有关该链接的问题，请参见the discussion in comments。lock orb $0, -1(%rsp)可能是避免延长溢出/重新加载的本地var的依赖链的不错选择。有关基准，请参见https://shipilev.net/blog/2014/on-the-fence-with-dependencies。在Windows x64(无红色区域)上，该空间应该不被使用，除非以后的调用或推送指令使用。
将存储转发到lock ed操作的负载端可能是一件事情(如果最近使用了该空间)，因此将锁定的操作保持在狭窄范围内是件好事。但是，作为一个完整的障碍，我不希望会有任何商店将其输出转发到其他任何东西，因此与正常情况不同，窄(1字节)的lock orb不会有不利的影响。
即使在Haswell上，与热线的堆栈空间相比，mfence还是很糟糕的，在Skylake上它甚至会阻塞OoO执行程序，可能更糟。 (与lock add相比，这对AMD也不利)。
关于c++ - x86上std::atomic_thread_fence(std::memory_order_seq_cst)的实现，而没有额外的性能损失，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/62337376/