std::mutex 不能控制线程启动顺序，但能强制执行顺序——关键不是“谁先跑”，而是“谁先完成”；它通过排他性锁机制使后一线程阻塞等待前一线程退出临界区，从而确保逻辑先后，而非依赖不可控的调度时机。

std::mutex 不能直接控制线程启动顺序，但能强制执行顺序——关键不是“谁先跑”，而是“谁先完成”。

---

为什么 std::thread 构造即启动，且顺序不可控

std::thread 对象在构造时就立即启动线程，不提供延迟或排队机制。操作系统调度器决定哪个线程先获得 CPU 时间片，哪怕你在代码里先构造 t1 再构造 t2，也不能保证 t1 的函数体先执行完。

• 常见错误现象：两个线程函数交叉打印、共享变量读写错乱、初始化未完成就被访问（比如类成员 name 在构造中被异步线程读取，输出乱码）
• 根本原因：线程启动和对象构造完成不同步；std::thread 不等待对象完全初始化就开跑
• 参数差异：传入成员函数时必须确保 this 指针所指对象已完整构造，否则是未定义行为

用互斥锁实现“A 完了 B 才开始”

这不是保护数据，而是用锁的排他性“卡住”第二个线程，直到第一个彻底退出临界区。

• 把整个线程函数逻辑包裹在同一个 std::mutex 的 lock()/unlock() 中
• 两个线程共用一把锁，第二线程调用 lock() 时会阻塞，直到第一线程调用 unlock()
• 注意：不要在锁内调用 std::this_thread::sleep_for 等长耗时操作，否则会无谓阻塞另一线程
• 示例片段：

  std::mutex mtx;
  void thread_a() {
      std::lock_guard<std::mutex> lk(mtx);
      // A 的全部工作
  }
  void thread_b() {
      std::lock_guard<std::mutex> lk(mtx);
      // B 的全部工作 —— 这里一定在 A 之后执行
  }

条件变量更适合“等某个状态成立再继续”

当需要更精细的唤醒时机（比如等 A 设置某个标志位），std::condition_variable 比死等互斥锁更高效。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

立即学习“C++免费学习笔记（深入）”；

• 避免忙等：线程挂起而非轮询，节省 CPU
• 必须配合 std::mutex 使用，且 wait() 内部会自动释放锁并重新获取
• 务必用 while 循环检查条件，防止虚假唤醒
• 典型模式：

  std::mutex mtx;
  std::condition_variable cv;
  bool ready = false;
  <p>void thread_a() {
  // 做事...
  {
  std::lock_guard<std::mutex> lk(mtx);
  ready = true;
  }
  cv.notify_one(); // 或 notify_all
  }</p><p>void thread_b() {
  std::unique_lock<std::mutex> lk(mtx);
  cv.wait(lk, []{ return ready; });
  // 此时 ready 为 true，安全执行后续逻辑
  }

C++26 的 execution_priority 只是提示，不是保证

std::execution_priority::high 这类新特性影响的是调度器优先级权重，不是执行先后的硬性约束。

• 它可能让高优先级任务更快被调度，但无法阻止低优先级任务在高优先级任务启动前就抢到 CPU
• 实时优先级（realtime）需系统支持（如 Linux 的 SCHED_FIFO），普通用户态程序通常无权使用
• 跨平台兼容性差：Windows 和 macOS 对优先级的实际响应远弱于 Linux
• 别指望靠它实现“先 A 后 B”——它解决的是响应延迟，不是逻辑依赖

真正要控制执行顺序，核心是让后一个线程主动等待前一个的完成信号，而不是依赖启动时机或调度偏好。锁和条件变量是目前最可靠、最可移植的手段，而任何试图绕过同步机制去“猜”执行顺序的做法，在多核环境下大概率失败。