std::atomic::is_always_lock_free =真正的含义是什么？

Question

我有以下代码：

#include <atomic>

int main () {
    std::atomic<uint32_t> value(0);
    value.fetch_add(1, std::memory_order::relaxed);
    static_assert(std::atomic<uint32_t>::is_always_lock_free);
    return 0;
}

它编译，因此它意味着std::atomic<uint32_t>::is_always_lock_free是真的。

然后，使用gcc 10和-std=c++20 -O3 -mtune=skylake-avx512 -march=skylake-avx512编写的汇编代码如下

0000000000401050 <main>:
  401050:       c7 44 24 fc 00 00 00    mov    DWORD PTR [rsp-0x4],0x0
  401057:       00 
  401058:       f0 ff 44 24 fc          lock inc DWORD PTR [rsp-0x4]
  40105d:       31 c0                   xor    eax,eax
  40105f:       c3                      ret    

许多帖子指出，读-修改-写操作(这里的fetch_add())不可能是没有锁的原子操作。

我的问题是，std::atomic::is_always_lock_free是true的真正含义是什么。

此页状态Equals true if this atomic type is always lock-free and false if it is never or sometimes lock-free.

那么，“这个原子类型总是没有锁”是什么意思呢？

Answer 1

这里的“锁”指的是“互斥”，而不是专门引用名为x86的lock指令前缀。

为任意类型实现std::atomic<T>的一种简单而通用的方法是T作为一个类，它包含一个T成员和一个std::mutex，在对象上的每个操作(加载、存储、交换、fetch_add等)周围都会锁定和解锁。然后，这些操作可以以任何旧的方式完成，并且不需要使用原子机器指令，因为锁保护它们。这个实现将是，而不是锁空闲的。

这种实现的一个缺点是，除了在一般情况下速度较慢外，如果两个线程试图同时对对象进行操作，其中一个线程将不得不等待锁，而锁实际上可能会阻塞并导致其被排定一段时间。或者，如果一个线程在保持锁的同时被调度出，那么所有想要对该对象进行操作的其他线程都必须等待第一个线程被调度回来，并首先完成它的工作。

因此，如果机器在T上支持真正的原子操作是可取的:一个其他线程不能干扰的单一指令或序列，如果被中断(或者根本不能中断)，它不会阻塞其他线程。如果对于某些类型的T，库能够用这样的实现专门化std::atomic<T>，那么这就是我们所说的无锁的意思。(这在x86上很混乱，因为用于此类实现的原子指令被命名为lock。在其他架构上，它们可能被称为其他东西，例如ARM64 64的ldxr/stxr独占加载/存储指令。

C++标准允许类型“有时是无锁的”：可能在编译时不知道std::atomic<T>是否没有锁，因为它取决于将在运行时检测到的特殊机器特性。甚至可能有些std::atomic<T>类型的对象是无锁的，而另一些则不是。这就是为什么atomic_is_lock_free是一个函数而不是常量的原因。它在这个特定的日子检查这个特定的对象是否是无锁的.

但是，在某些实现中，可以保证某些类型在编译时始终是无锁的。这就是is_always_lock_free用来表示的，并且注意它是一个constexpr bool而不是一个函数。