何时需用std::promise::set_value_at_thread_exit()？detached线程场景解析

为什么线程detach时要等thread_local销毁后再修改future共享状态？ #

当线程被detach后，它的生命周期和发起线程完全独立——发起线程可能在子线程还没做完所有收尾工作时，就通过future::get()获取结果。

如果用普通的set_value()/set_exception()，会立刻把future置为就绪状态。这时候发起线程拿到结果后，很可能误以为子线程已经彻底结束，但实际上子线程还没走到销毁thread_local变量的阶段。thread_local变量的销毁是线程退出流程的最后一步，要是future就绪的时机早于这个步骤，就可能出现时序冲突：比如发起线程拿到的结果依赖thread_local变量的状态，或者子线程的thread_local析构逻辑需要和future的就绪状态严格同步，提前就绪就会破坏这种同步，引发不可预料的问题。

而set_value_at_thread_exit()/set_exception_at_thread_exit()会把设置future状态的操作，推迟到线程所有thread_local变量销毁之后再执行。这样发起线程通过get()拿到结果时，子线程的所有清理工作已经完成，不会出现资源访问的时序错误。

改用set_value()/set_exception()会导致崩溃或未定义行为的场景 #

• 返回thread_local变量的指针/引用：如果future的结果是指向thread_local变量的指针或引用，set_value()会立即让future就绪。发起线程调用get()后直接访问该指针/引用时，子线程可能还没销毁thread_local（此时访问可能暂时正常，但后续子线程销毁时会失效），或者刚好在销毁过程中，直接访问到已经失效的内存，触发崩溃或未定义行为。
• thread_local析构函数依赖future状态同步：比如thread_local变量的析构函数需要修改某个共享数据，而发起线程拿到future结果后会读取这个数据。如果future提前就绪，发起线程先读了数据，子线程析构时再修改，就会导致数据不一致；或者析构函数需要等待发起线程处理完future结果，但发起线程已经处理完退出，析构时操作不存在的资源，引发未定义行为。
• 子线程清理操作依赖future未就绪状态：子线程调用set_value()后还有清理逻辑，而发起线程拿到future结果后就释放了子线程还在使用的共享资源，子线程清理时访问无效资源，直接崩溃。
• 异常传播的时序冲突：用set_exception()立即设置异常，发起线程捕获异常后直接释放相关资源，但子线程此时还在销毁thread_local，而这些销毁逻辑依赖已被释放的资源，导致未定义行为。

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