c++ - std::atomic::is_always_lock_free = true 到底是什么意思？

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真正的意思。

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

那么“这种原子类型总是无锁的”是什么意思呢？

Answer 1

这里的“Lock”是“mutex”的意思，并不是专门指名为lock的x86指令前缀。 .

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

这种实现的一个缺点，除了一般来说很慢之外，是如果两个线程同时尝试对对象进行操作，其中一个将不得不等待锁，这实际上可能会阻塞并导致它被安排一段时间。或者，如果一个线程在持有锁的同时被调度出去，所有其他想要对该对象进行操作的线程都必须等待第一个线程重新调度并首先完成其工作。

所以如果机器支持真正的原子操作 T 是可取的。 :其他线程不能干扰的单个指令或序列，并且如果被中断(或者可能根本不能被中断)也不会阻塞其他线程。如果对于某些类型 T图书馆已经能够特化std::atomic<T>有了这样的实现，这就是我们所说的无锁的意思。 (这在 x86 上只是令人困惑，因为用于此类实现的原子指令被命名为 lock。在其他架构上，它们可能被称为其他东西，例如 ARM64 的 ldxr/stxr 专有加载/存储指令。)

C++ 标准允许类型“有时无锁”:也许在编译时不知道 std::atomic<T>将是无锁的，因为它依赖于在运行时检测到的特殊机器特性。甚至有可能是 std::atomic<T> 类型的某些对象。是无锁的，而其他的则不是。这就是为什么atomic_is_lock_free是函数而不是常数。它检查此特定对象在特定日期是否是无锁的。

但是，对于某些实现，可能会保证某些类型在编译时始终是无锁的。就是这样 is_always_lock_free用于表示，注意是constexpr bool而不是一个函数。