无锁编程：原子值有多新鲜？

Question

一个原子变量在多个同时运行的线程之间共享。 据我所知，线程可以读取过时的值来执行轻松的加载：

x.load(std::memory_order_relaxed)

如果我们使用发布获取同步怎么办？ 据我所知，执行获取的线程可以确保查看释放线程已将哪些内容写入变量。

// Thread 1:
x.store(33, std::memory_order_release);

// Thread 2:
x.load(std::memory_order_acquire)

在这种情况下，线程2总是会看到新值吗？

现在，如果我们将执行轻松存储的第三个线程添加到前面的示例中，则线程2可能看不到该更新，因为仅在线程1和2之间建立了同步。 我对么？

最后，据说读-修改-写操作总是对新值进行操作。 这是否意味着它们迫使线程“查看”其他线程所做的更新，所以如果我们在执行read-modify-write操作之后加载，我们将看到的值至少与该操作一样新鲜？

// Thread 1:
x.fetch_add(1, std::memory_order_relaxed); // get the fresh value and add 1
if (x.load(std::memory_order_relaxed) == 3) // not older than fetch_add
    fire();

// Thread 2:
x.fetch_add(2, std::memory_order_relaxed); // will see thread 1 modification
if (x.load(std::memory_order_relaxed) == 3) // will see what fetch_add has put in x or newer
    fire();

对于x最初为零，我可以确定在这种情况下将至少fire一次fire吗？ 我所有的测试都证明它可以工作，但也许这只是我的编译器或硬件的问题。

我也对订购感到好奇。 x修改与加载之间存在明显的依存关系，因此尽管我指定了宽松的顺序，但我认为这些指令不会重新排序。 还是我错了？

Answer 1

关键是memory_order_relaxed意味着fetch_add不会将加载/存储顺序排序到任何其他位置。 它会做任何必要的事情，而不是原子的。 但是，单个线程内的依存关系顺序仍然适用。

---

为了使fetch_add具有原子性，它必须防止试图同时执行的任何其他fetch_add对读取的相同输入值进行运算。 几乎所有内容都使用MESI高速缓存一致性协议的派生形式，因此在实践中，通过将高速缓存行从读取到写入保持在“ M”状态，可以完成原子的fetch_add。 （或使用LL / SC ，检测到未发生这种情况，然后重试。）另请参见num ++是否对于'int num'是原子的？ 有关x86的更详细说明。

C ++没有具体说明其实现方式，但了解C ++尝试公开哪种硬件操作可能会很有用。

---

对于x最初为零的情况，我可以确定在这种情况下至少会调用一次fire吗？

是的，它将至少运行一次。 它可以运行两次，因为这两种加载都可能看到第二个fetch_add的结果。

负载总是看到x的值，该值至少已由其自身线程中的fetch_add更新。 memory_order_relaxed不允许线程观察自己发生的操作乱序，而fetch_adds确实按某种顺序发生。 因此，至少“第二”的线程将看到x == 3 。

顺序是无法预料的。 您可以通过查看fetch_add的返回值来观察它，而不是使用单独的加载。 （此代码不遵守fetch_add建立的顺序，因为多个线程可以获得相同的值。为此，您需要将值捕获为单个原子操作的一部分。）

---

我也对订购感到好奇。 x修改与加载之间存在明显的依存关系，因此尽管我指定了宽松的顺序，但我认为这些指令不会重新排序。

在运行时和编译时对内存进行重新排序以及无序执行都可以保留单个线程的行为。 所有这些东西（包括编译器的“按样规则”）的黄金法则是“不要破坏单线程代码”。

但是不能保证这些操作对其他线程全局可见的顺序。 在x.fetch_add之后， x.load的存储部分可以对其他线程全局可见。 它不会在x86上使用，因为x86不会对具有相同地址的后续加载的存储进行重新排序（但是， 即使存储和加载部分重叠 ， 也可以对其他地址进行StoreLoad重新排序）。

第三个线程可能会看到T1和T2的操作发生的顺序与T1看到T2的操作的发生顺序不同。 （即，不必使用所有线程都同意的总顺序，除非您使用顺序一致性 。）

请注意，仅可以间接地“观察”变得全局可见的负载：通过查看线程完成的其他存储，以找出必须加载的值。 但是，负载是订购中最重要的部分。

因此，如果fire()向内存中写入内容，则第三个线程可能会在x==0情况下看到这种情况。 只有（在线程3上）看起来像T1的加载发生在任一线程中的fetch_add之前，才有可能。 即使线程3使用x.fetch_add(mo_relaxed)观察x的值，C ++也允许这样做。 但是就像我说的那样，您不会在x86上看到它。

---

请注意，“依存关系排序”是具有其他含义的短语。 即使在顺序较弱的CPU上，加载指针然后对其取消引用也可以确保在两次加载之间不会发生LoadLoad重新排序。 只有一种架构没有做到这一点：Alpha需要一个障碍来使其工作。 这是memory_order_consume和memory_order_relaxed分开的原因之一。

如果mo_release生产者正在发布指针，则可以使用memory_order_consume而不是memory_order_acquire进行更便宜的同步。 （编译器通常只是为了加强获取而增加消耗，因为这很难实现。）

依赖顺序的mo_consume含义适用于两个不同的内存位置：指针和缓冲区。 这与线程始终按顺序看到自己的动作这一事实完全不同。

---

当只有一个对象时，线程将始终看到的数据至少与其最新存储一样新。 （按其观察到的操作顺序是新的，而不是绝对时间中的新内容！这仅意味着线程无法存储值，然后使其下一次读取发现该值已从已经存储的存储中还原为一个值。在fetch_add之前看到。）

对这些东西进行推理是不容易的（例如，其他线程看到的全局顺序，相对于所涉及线程之一看到的顺序）。 列举所有可能或不可能的所有令人惊讶的重新排序也很棘手。

无锁和stdatomic标签Wiki中有一些链接。 我特别推荐Jeff Preshing的博客 。 他讲得很好，并发表了许多好文章。