忙等待循环中是否需要内存屏障或原子操作？

Question

考虑以下spin_lock() 实现，最初来自this answer：

void spin_lock(volatile bool* lock)  {  
    for (;;) {
        // inserts an acquire memory barrier and a compiler barrier
        if (!__atomic_test_and_set(lock, __ATOMIC_ACQUIRE))
            return;

        while (*lock)  // no barriers; is it OK?
            cpu_relax();
    }
}

我已经知道的：

• volatile 防止编译器在 while 循环的每次迭代中优化出 *lock 重新读取；
• volatileinserts neither memory nor compiler barriers;
• 这样的实现实际上在 GCC 中适用于 x86（例如在 Linux 内核中）和一些其他架构；
• 在通用架构的spin_lock() 实现中至少有一个内存和编译器屏障is required；此示例将它们插入到__atomic_test_and_set()。

问题：

1. 这里的volatile 是否足够，或者是否有任何架构或编译器在while 循环中需要内存或编译器屏障或原子操作？

   1.1 按照C++标准？

   1.2 在实践中，对于已知的架构和编译器，特别是对于 GCC 及其支持的平台？

2. 这个实现在 GCC 和 Linux 支持的所有架构上是否安全？ （在某些架构上至少效率低下，对吧？）
3. 根据C++11 及其内存模型，while 循环是否安全？

---

有几个相关的问题，但我无法从它们中构建出明确明确的答案：

• Q: Memory barrier in a single thread

  原则上：是的，如果程序执行从一个内核移动到下一个内核，它可能不会看到前一个内核上发生的所有写入。

• Q: memory barrier and cache flush

  在几乎所有现代架构上，缓存（如 L1 和 L2 缓存）都由硬件确保一致。无需刷新任何缓存即可使内存对其他 CPU 可见。

• Q: Is my spin lock implementation correct and optimal?

• Q: Do spin locks always require a memory barrier? Is spinning on a memory barrier expensive?

• Q: Do you expect that future CPU generations are not cache coherent?

Answer 1

来自Wikipedia page on memory barriers：

... 其他架构，例如 Itanium，提供单独的“获取”和“释放”内存屏障，从读取器（接收器）或写入器（来源）。

对我来说，这意味着 Itanium 需要一个合适的栅栏来使读/写对其他处理器可见，但这实际上可能只是为了排序。我认为这个问题真的可以归结为：

是否存在一种架构，如果没有指示，处理器可能永远不会更新其本地缓存？我不知道答案，但如果你以这种形式提出问题，那么有人否则可能。在这样的架构中，您的代码可能会进入无限循环，其中*lock 的读取总是看到相同的值。

就一般 C++ 合法性而言，在您的示例中设置一个原子测试和设置是不够的，因为它只实现了一个栅栏，允许您在进入 while 循环时看到 *lock 的初始状态但看不到它何时发生变化（这会导致未定义的行为，因为您正在读取在另一个线程中更改而没有同步的变量） - 所以您的问题（1.1/3）的答案是 no .

另一方面，在实践中，(1.2/2) 的答案是肯定的（给定 GCC's volatile semantics），只要架构保证高速缓存的一致性而没有显式的内存栅栏，这对于 x86 和可能对于许多人来说都是正确的架构，但我不能给出一个明确的答案，它是否适用于 GCC 支持的所有架构。然而，根据语言规范故意依赖技术上未定义行为的代码的特定行为通常是不明智的，尤其是如果不这样做就可能获得相同的结果。

顺便说一句，鉴于存在memory_order_relaxed，似乎没有理由在这种情况下不使用它，而是尝试通过使用非原子读取来手动优化，即将示例中的while循环更改为：

    while (atomic_load_explicit(lock, memory_order_relaxed)) {
        cpu_relax();
    }

例如，在 x86_64 上，原子加载变为常规的 mov 指令，优化的汇编输出与原始示例基本相同。

Answer 2

这很重要：在 C++ 中，volatile 与并发完全无关！ volatile 的目的是告诉编译器它不应优化对受影响对象的访问。它确实不告诉 CPU 任何事情，主要是因为 CPU 已经知道内存是否为 volatile。 volatile 的目的是有效地处理内存映射 I/O。

C++ 标准在第 1.10 节 [intro.multithread] 中非常清楚，对在一个线程中修改并在另一个线程中访问（修改或读取）的对象的非同步访问是未定义的行为。避免未定义行为的同步原语是库组件，如原子类或互斥锁。该子句仅在信号上下文（即volatile sigatomic_t）和向前进展的上下文中提及volatile（即，线程最终将执行具有可观察效果的操作，例如访问volatile 对象或做 I/O）。没有提到 volatile 与同步一起使用。

因此，对跨线程共享的变量的不同步评估会导致未定义的行为。是否声明 volatile 与这种未定义的行为无关。

Answer 3

1. 这里的 volatile 是否足够，或者是否有任何架构或编译器在 while 循环中需要内存或编译器屏障或原子操作？

易失性代码会看到变化吗？是的，但不一定像存在记忆障碍那样快。在某些时候，会发生某种形式的同步，并且会从变量中读取新状态，但无法保证代码中其他地方发生了多少。

1.1 根据C++标准？

来自cppreference : memory_order

内存模型和内存顺序定义了代码需要处理的通用硬件。对于在执行线程之间传递的消息，需要发生线程间发生之前的关系。这需要...

• A 与 B 同步
• A 在 B 之前有一个 std::atomic 操作
• A 间接与 B 同步（通过 X）。
• A 在 X 之前排序，线程间发生在 B 之前
• 线程间发生在 X 之前，而 X 线程间发生在 B 之前。

由于您没有执行任何这些情况，您的程序的某些形式在某些当前硬件上可能会失败。

实际上，时间片的结束会导致内存变得连贯，或者非自旋锁线程上的任何形式的屏障都会确保缓存被刷新。

不确定易失性读取获得“当前值”的原因。

1.2 在实践中，对于已知的架构和编译器，特别是对于 GCC 及其支持的平台？

由于代码与通用 CPU 不一致，从 C++11 开始，该代码很可能无法在尝试遵守标准的 C++ 版本中执行。

来自cppreference : const volatile qualifiers 易失性访问阻止优化将工作从之前移动到之后，从之后移动到之前。

“这使得 volatile 对象适合与信号处理程序通信，但不适用于另一个执行线程”

因此，实现必须确保从内存位置读取指令，而不是从任何本地副本。但它不必确保通过缓存刷新易失性写入以在所有 CPU 上产生一致的视图。从这个意义上说，在写入 volatile 变量后多久对另一个线程可见是没有时间界限的。

另见kernel.org why volatile is nearly always wrong in kernel

此实现在 GCC 和 Linux 支持的所有架构上是否安全？ （至少在某些架构上效率很低，对吧？）

无法保证 volatile 消息会脱离设置它的线程。所以不是很安全。在 linux 上它可能是安全的。

根据 C++11 及其内存模型，while 循环是否安全？

否 - 因为它不创建任何线程间消息传递原语。