为什么带有 std::memory_order_relaxed 的自旋锁可以正确执行？

Question

我用 C++11 原子库实现了一个自旋锁：

class SpinLock {
  atomic_bool latch_;

  public:
  SpinLock() :latch_(false){
  }
  void lock() {
    while(tryLock() == false);
  }
  bool tryLock() {
    bool b = false;
    return latch_.compare_exchange_weak(b,true,std::memory_order_relaxed);
  }
  void unlock() {
    latch_.store(false,std::memory_order_relaxed);
  }
};

我通过产生多个线程来测试正确性如下：

static int z = 0;
static SpinLock spinLock;
static void safeIncrement(int run) {
  while(--run >= 0) {
    std::lock_guard<SpinLock> guard(spinLock);
    ++z;
  }
}

static void test(int nThreads =2) {
  std::vector<std::thread*> workers(nThreads);
  z = 0;
  for(auto& ptr : workers) ptr = new std::thread(safeIncrement,1<<20);
  for(auto ptr : workers) ptr->join();
  cout<<"after increment: " <<z << " out of " << (1<<20) * nThreads<<endl;
  for(auto ptr : workers) delete ptr;
}
int main() {

  test(4);

  return 0;

}

令我感到惊讶的是，最后的总数加起来是一个正确的值，顺序宽松。通过这篇文章：http://en.cppreference.com/w/cpp/atomic/memory_order，宽松的顺序意味着“没有同步或排序约束”，所以一个线程的更改并不意味着其他线程可以看到，对吧？为什么还是正确的？
（测试在 Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz 上运行）

编辑：（感谢 Maxim 的评论）更新了代码：初始化 SpinLock 中的数据成员，并更新了测试代码。

Answer 1

C++11 标准为原子操作指定了最弱的保证。并非所有硬件都可以完全匹配每个最弱的保证，因此编译器和库编写者有时必须“四舍五入”到更强大的操作。例如，x86 上的所有原子读取-修改-写入操作都隐含了memory_order_acq_rel。

此外，硬件架构的特定实现可能比硬件手册所说的具有更强的保证。例如，早期的 Itaniums 实现了 memory_order_acq_rel 语义，即使对于一些只承诺 memory_order_release 的硬件指令。

理论上，您的代码可能会在 x86 上失败，因为尊重原子操作的内存顺序涉及硬件和编译器。激进的编译器可以合法地将 'z' 的负载（也可能还有存储！）移到仅使用 memory_order_release 排序的 tryLock 操作之上。

Answer 2

我看到至少 GCC 6.3 在 x86-64 上为放松和发布/获取生成相同的代码。因此，结果相同也就不足为奇了。因此，要查看差异，您可能需要比 x86-64 提供的 TSO 更轻松的内存架构。可能，它可能是 ARM。

Answer 3

在互斥体实现上使用宽松的排序约束会导致灾难。
根据定义，互斥锁旨在在线程之间同步数据。 acquire 和 release 这两个术语与互斥锁密切相关； 您获取一个互斥锁，更改受它保护的数据并释放该互斥锁，以便在获得相同互斥锁后数据对另一个线程可见。

您所指的文章指出，对于宽松的操作，“没有同步或排序约束”......它适用于围绕互斥锁的内存操作， 不是互斥锁本身。通过宽松的排序，本应受互斥体保护的数据实际上可能会被多个线程同时修改（引入数据竞争）。

在诸如X86 这样具有隐式获取/释放语义的更强有序架构上，您将摆脱这种实现（因此您的测试成功）。 但是，在使用较弱内存排序的架构上运行它，例如Power 或ARMv7，你就有麻烦了。

您在 cmets 中建议的顺序是正确的。