继承std::thread的潜在竞态问题：理论正确性与实际场景

从设计角度看，继承std::thread似乎很有吸引力——这类派生类本质是带扩展功能的线程，线程函数可以设为私有成员、封装内部数据，还能控制外部访问与交互，必要时内置锁定/同步机制，完全符合RAII原则（线程要么运行要么终止）。

但根据C++标准定义，std::thread构造函数的完成，与新线程中线程函数副本的启动是同步的（按std::memory_order规则）。这就引出一个问题：派生类的初始化是在基类构造完成后才开始的，那理论上这种写法会引发未定义行为吗？

举个典型的错误示例：

class MyThread : public std::thread {
  std::unique_ptr<Something> thing;

  void threadOp() {
    thing.reset(new Something{});
    // 其他操作...
  }

public:
  MyThread()
    : std::thread{ &MyThread::threadOp, this}
    { }
};

并发的核心是“操作可能同时发生”——理论上，调用MyThread构造函数的主线程可能被抢占，新线程提前启动并执行threadOp分配资源，而派生类成员thing的默认构造（在基类构造后才会隐式执行）可能覆盖它的值，甚至新线程可能看不到后续的初始化，直接操作未初始化的nullptr或垃圾内存。

1. 上述理论推理是否正确？ #

完全正确。

C++对象的构造顺序是严格规定的：基类构造函数先执行，随后初始化派生类的成员变量，最后才进入派生类构造函数的函数体。在这个示例里，基类std::thread的构造函数启动了新线程，并且传入了this指针——此时MyThread的成员thing还未完成初始化。

新线程启动后访问thing，本质是在操作一个未完全构造的对象成员，这直接违反了C++对象生命周期的规则，属于明确的数据竞态，会触发未定义行为。比如thing的默认构造（将指针置为nullptr）和线程中的reset操作可能同时进行，导致内存操作混乱；或者新线程读取到thing的未初始化垃圾值，引发崩溃或不可预测的行为。

2. 哪些实际场景下可能观测到这类竞态？ #

这类竞态在以下场景中更容易被观测到：

• 多核CPU环境：主线程在基类构造完成后，被调度器切换到其他核心的新线程，此时新线程会优先执行threadOp，直接操作未初始化的thing成员。
• 高负载系统：主线程构造MyThread时，系统资源紧张、调度频繁，很容易出现构造过程被抢占的情况，新线程提前执行。
• 开启编译器优化时：编译器可能对构造顺序做指令重排（只要符合as-if规则），延迟派生类成员的初始化时机，导致新线程更大概率访问到未初始化的成员。
• 成员变量是复杂类型时：如果thing不是unique_ptr而是更复杂的对象，其构造过程耗时更长，竞态发生的概率会显著提升，甚至可能出现部分构造的对象被线程访问的情况。

内容的提问来源于stack exchange，提问作者Ichthyo