C ++：释放构造函数中所需的障碍，该构造函数创建访问构造对象的线程

Question

如果我在构造函数中创建一个线程，并且如果该线程访问该对象，我是否需要在该线程访问该对象之前引入一个释放屏障？具体来说，如果我有下面的代码 (wandbox link)，我是否需要在构造函数（注释掉的行）中锁定互斥量？我需要确保 worker_thread_ 看到对 run_worker_thread_ 的写入，这样它就不会立即退出。我意识到在这里使用原子布尔值更好，但我有兴趣了解此处的内存排序含义。根据我的理解，我认为我确实需要在构造函数中锁定互斥锁，以确保构造函数中互斥锁的解锁提供的释放操作与 [=13= 中的互斥锁锁定提供的获取操作同步] 通过调用 shouldRun()。

class ThreadLooper {
 public:
   ThreadLooper(std::string thread_name)
       : thread_name_{std::move(thread_name)}, loop_counter_{0} {
        //std::lock_guard<std::mutex> lock(mutex_);
        run_worker_thread_ = true;
        worker_thread_ = std::thread([this]() { threadLoop(); });
        // mutex unlock provides release semantics
   }

   ~ThreadLooper() {
     {
        std::lock_guard<std::mutex> lock(mutex_);
        run_worker_thread_ = false;
     }
     if (worker_thread_.joinable()) {
       worker_thread_.join();
     }
     cout << thread_name_ << ": destroyed and counter is " << loop_counter_
          << std::endl;     
   }

 private:
  bool shouldRun() {
      std::lock_guard<std::mutex> lock(mutex_);
      return run_worker_thread_;
  }

  void threadLoop() {
    cout << thread_name_ << ": threadLoop() started running"
         << std::endl;
    while (shouldRun()) {
      using namespace std::literals::chrono_literals;
      std::this_thread::sleep_for(2s);
      ++loop_counter_;
      cout << thread_name_ << ": counter is " << loop_counter_ << std::endl;
    }
    cout << thread_name_
         << ": exiting threadLoop() because flag is false" << std::endl;
  }

  const std::string thread_name_;
  std::atomic_uint64_t loop_counter_;
  bool run_worker_thread_;
  std::mutex mutex_;
  std::thread worker_thread_;
};

这也让我更普遍地考虑是否要在构造函数中初始化一堆常规 int（非原子）成员变量，然后通过一些 public 方法从其他线程读取这些变量，如果我除了读取这些变量的方法之外，还需要类似地在构造函数中锁定互斥量。这对我来说似乎与上面的情况略有不同，因为我知道该对象将在任何其他线程访问它之前被完全构造，但这似乎并不能确保该对象的初始化对其他线程不可见构造函数中的释放操作。

Answer 1

您不需要任何障碍，因为guaranteed thread 构造函数与传递给它的函数的调用同步。标准语：

The completion of the invocation of the constructor synchronizes with the beginning of the invocation of the copy of f.

比较正式的证明： run_worker_thread_ = true;(A) 排序在 thread 对象创建 (B) 根据完整表达式 evaluation order. The thread object construction synchronizes with the closure object execution (C) according to the rule cited above. Hence, A inter-thread happens before C.

B 之前的序列，B 与 C 同步，A 发生在 C 之前 -> 这是标准术语中的正式证明。

并且在分析 C++11+ 时代的程序时，您应该坚持 C++ 的内存和执行模型，而忘记编译器可能会或可能不会做的障碍和重新排序。这些只是实现细节。唯一重要的是 C++ 术语中的形式证明。编译器必须遵守并做（和不做）任何它能遵守的规则。

但为了完整起见，让我们用编译器的眼光看一下代码，并尝试理解为什么在这种情况下它不能重新排序。我们都知道 "as-if" 规则，根据该规则，编译器可能会在您无法判断某些指令已重新排序时对其进行重新排序。所以如果我们有一些 bool 标志设置：

flag1 = true; // A
flag2 = false;// B

允许执行以下行：

flag2 = false;// B
flag1 = true;// A

尽管 A 在 B 之前排序。它可以做到这一点，因为我们无法区分，但我们无法仅通过观察程序行为来捕捉它对指令的重新排序，因为除了 "sequenced before"这些线之间没有关系。但是让我们回到我们的案例：

run_worker_thread_ = true; // A
worker_thread_ = std::thread(...); // B

看起来这种情况与上面的 bool 变量相同。如果我们不知道 thread 对象（除了在 A 表达式之后排序）与 something[=64 同步，情况就会如此=]（为简单起见，让我们忽略这件事）。但是正如我们发现的那样，如果某件事排在另一件事之前，而另一件事又与另一件事同步，那么它就发生在那件事之前。所以标准要求 A 表达式发生在我们的 B 表达式同步之前。

并且这个事实禁止编译器重新排序我们的 A & B 表达式，因为如果它这样做的话我们突然可以分辨出差异。因为如果它这样做了，那么 C 表达式（某物）可能看不到 A 提供的可见副作用。因此，仅通过观察程序执行，我们就可能发现作弊的编译器！因此，它必须使用一些障碍。不管它只是一个编译器障碍还是一个硬件障碍，它都必须存在以保证这些指令不会被重新排序。所以你可能认为它在构造完成时使用释放栅栏，在闭包对象执行时使用获取栅栏。这将粗略地描述幕后发生的事情。

您似乎也将互斥量视为一种神奇的东西，它总是有效并且不需要任何证明。因此，出于某种原因，您相信 mutex 而不是 thread。但问题是它没有魔法，它唯一的保证是 lock 与之前的 unlock 同步，反之亦然。因此它提供 与 thread 相同的保证。

C ++：释放构造函数中所需的障碍，该构造函数创建访问构造对象的线程

C++: Release barriers required in constructor that creates a thread that accesses the constructed object

c++

multithreading

memory-barriers

c++11