如果我在构造函数中创建一个线程，并且如果该线程访问该对象，我是否需要在该线程访问该对象之前引入一个释放屏障？具体来说，如果我有下面的代码 ( wandbox link )，我是否需要在构造函数中锁定互斥量(注释掉的行)？我需要确保 worker_thread_ 看到对 run_worker_thread_ 的写入，这样它就不会立即退出。我意识到在这里使用原子 bool 值更好，但我有兴趣了解此处的内存排序含义。根据我的理解，我认为我确实需要在构造函数中锁定互斥锁，以确保构造函数中互斥锁的解锁提供的释放操作与 threadLoop 中的互斥锁锁定提供的获取操作同步() 通过调用 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)方法从其他线程读取这些成员变量，如果我需要类似地锁定除了在读取这些变量的方法中之外，构造函数中的互斥锁。这对我来说似乎与上面的情况略有不同，因为我知道该对象将在任何其他线程访问它之前被完全构造，但这似乎并不能确保该对象的初始化对其他线程不可见构造函数中的释放操作。

最佳答案

你不需要任何障碍因为它是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 . thread 对象构造同步闭包对象执行(C)根据上面引用的规则。因此，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 之前。它可以做到这一点，因为我们无法分辨差异，我们无法仅通过观察程序行为来捕捉它重新排序我们的指令，因为除了“先于排序”之外，没有任何关系在这些线之间。但是让我们回到我们的案例:

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

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

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

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

关于C++:释放构造函数中所需的障碍，该构造函数创建访问构造对象的线程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57670289/