使用std::promise::set_value_at_thread_exit()触发ThreadSanitizer警告的疑问

我们在生产环境中使用如下异步工作模式的最小示例，代码中会始终调用join()确保线程工作完成：

#include <future>
#include <iostream>
#include <thread> 

int main(void) {
    std::promise<void> p;
    std::shared_future<void> f = p.get_future().share();
    
    std::thread t = std::thread([&p] {
        p.set_value_at_thread_exit();
        std::cout << "Hello thread." << std::endl;
    });
    
    f.wait();
    std::cout << "Hello main." << std::endl;
    
    t.join();
    
    return 0; 
}

使用set_value_at_thread_exit()时，Clang和GCC的ThreadSanitizer都会触发警告，但将其替换为在线程函数末尾调用p.set_value()则无警告。现需明确两个问题：

1. 为何set_value_at_thread_exit()会引发数据竞争，而set_value()不会？（cppreference上的类似示例也存在相同问题）
2. 在始终join线程的前提下，两种方式的功能差异是什么？若在线程返回前最后调用p.set_value()，能否确保线程工作已完成？

问题1：数据竞争的原因 #

set_value()会立刻把promise的状态设为就绪，同时唤醒等待的future，整个操作是原子性的，不会和线程后续的操作产生竞争。

而set_value_at_thread_exit()的逻辑不一样：它不会马上修改promise状态，而是先给线程注册一个退出回调，等线程把所有局部对象都销毁完，真正要退出的时候，才去设置promise的就绪状态。这时候主线程可能已经被f.wait()唤醒，在执行后续代码，甚至已经开始等t.join()了——ThreadSanitizer会检测到主线程操作std::thread对象（join）和子线程退出阶段操作promise之间，没有严格的同步顺序，所以会触发竞争警告。

说白了，set_value_at_thread_exit()的实际生效时机是线程退出时，这个时机和主线程的join操作没明确的同步点，TSan就认为有风险；而set_value()是子线程运行过程中就完成了同步，主线程被唤醒后，子线程的后续操作和主线程的执行是明确同步的，不会触发警告。

问题2：功能差异与工作完成的保证 #

功能差异 #

• set_value()：调用后马上标记promise就绪，主线程的f.wait()会立刻醒过来，这时候子线程可能还在跑后面的代码（比如示例里的cout输出）。
• set_value_at_thread_exit()：子线程会先把所有代码执行完，包括销毁所有局部对象，等真正要退出的时候才标记promise就绪，主线程的f.wait()要等到子线程所有工作都做完才会被唤醒。

工作完成的保证 #

如果在线程返回前最后一行调用p.set_value()，从实际执行来看，子线程的所有工作已经做完了，后面没别的代码要跑，理论上能确保工作完成。但有个细微差别：set_value_at_thread_exit()会等线程所有局部自动对象销毁完，再触发promise就绪；而手动在最后调用set_value()的话，如果set_value()之后还有局部对象要析构（比如函数结束时的隐式析构），那主线程被唤醒时，子线程可能还在执行析构逻辑。不过要是你的线程函数最后一行就是set_value()，而且之后没有需要销毁的重要对象，那两者实际效果差不多。

但要注意：哪怕你在最后调用set_value()，从标准内存模型的角度，主线程被唤醒后，子线程后续的操作（比如局部对象析构）和主线程的同步，是靠后面的t.join()来保证的——因为join()会确保子线程所有操作（包括析构）都完成后，主线程才继续走。所以只要你始终调用join()，不管用哪种方式，最终都能保证子线程的所有工作（包括对象销毁）全部完成。

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