c++ - C++ 11:16字节的atomic <>变量是否自动在16字节的边界上对齐以允许CMPXCHG16B指令？

Question

16字节atomic<>变量是否自动在16字节边界上对齐，以允许编译器/运行时库有效地使用x86 CMPXCHG16B指令？还是我们应该始终为所有此类变量手动指定alignas(16)？

Answer 1

如果库完全使用std::atomic<>而不是16字节对象的互斥锁，则alignas的任何体面实现都将使用lock cmpxchg16b本身来提高lock cmpxchg16b的效率。

并非所有的实现都可以，例如，我认为MSVC的标准库使用标准的互斥锁回退使16字节对象完全无锁。

不需要alignas(16)上的atomic<T> 。

如果您具有要使用T的普通atomic_ref对象，则只需要对原子进行手动对齐。 atomic_ref<>没有对齐现有T对象的机制。设计的当前版本公开了您应该使用的required_alignment成员。这样做是为了您的正确性。 (否则，您得到的UB可能意味着撕裂lock RMW撕裂或在整个系统范围内的性能极其缓慢。)

 // for atomic_ref<T>
alignas(std::atomic_ref<T>::required_alignment) T sometimes_atomic_var;

 // often equivalent, and doesn't require checking that atomic_ref<T> is supported
alignas(std::atomic<T>) T sometimes_atomic_var;
 // use the same alignment as atomic<T>

请注意，在缓存行边界上分割的未对齐 lock cmpxchg16b仍然是原子的，但速度非常慢(与任何 lock ed指令相同:原子RMW的原子性保证不取决于对齐)。更像是实际的公交车锁，而不仅仅是本地的 cache lock delaying MESI responses。

较窄的原子绝对需要自然对齐以确保正确性，因为pure-load和pure-store可以编译为 asm pure load or store where HW guarantees require some alignment。

但是只有通过 lock cmpxchg16b保证16字节对象是原子的，因此 .load()和 .store()必须使用 lock cmpxchg16b来实现。 (使用CAS(0,0)加载以获取旧值，或者将0替换为自身或不执行任何操作，然后使用CAS重试循环进行存储。这很烂，但比互斥锁要好一些。它没有read-您希望从无锁 load获得的方面可扩展性，这是GCC7和更高版本不再将 atomic<16-byte-object>宣传为无锁的原因之一，尽管它仍会在调用的libatomic函数中使用 lock cmpxchg16b而不是内联 lock cmpxchg16b)