如何转发可能是右值及其(可变)参数的可调用对象，以使执行对于待生成的线程而言100％正确且可靠？
我的猜测是答案将是“等待条件变量”，但我想确定。
我为什么要问这个？
我有一个Homebrewn线程实现，在std::thread出现之前很久就可以100％可靠地工作了。它仍然可以正常工作。现在我们确实有了std::thread了一段时间(或多或少，这就是说……由于依赖于gthr/pthread，MinGW类型的发行版对线程的支持不是那么好，可悲的是，我绝对需要支持Win32)。std::thread具有这个很酷的功能，您可以传递一个lambda以及任意参数，并且它以某种方式起作用。棒极了。
我的实现要求您要么从基类派生，要么将指针传递给状态块，该状态块包含一个函数指针和几个数据指针(与lambda基本上相同，但丑陋，笨拙且不灵活) 。
我并不是真的需要lambda功能，但是它很酷，所以我认为我会实现它。这有多难。
判决
该代码简单明了，并且工作得非常好，除了它不是。我发现在多次成功运行并使用内联lambda创建两个线程后，它不起作用。换句话说
class thread { [...] template<typename F, typename... A> thread(F&& f, A&&... args) : handle( detail::spawn_thread(std::forward<>(...)) ) { } };
thread a([](){...}); // works fine 100% of the time alone, but
thread b([](){...}); // one failure out of 20, if both are present
嗯，真有趣。怎么会这样？甚至没有足够的代码来产生严重故障的可能性。转发通用引用，生成带有指向参数的指针的线程，所有内容看起来都是纯真的。
除此以外，如果
spawn_thread返回时另一个线程尚未启动(这在我的系统中大约每20次发生一次)。因为在这种情况下，新线程将尝试读取您刚刚释放并覆盖的状态。
标准库方法
让我们看看标准库是如何做到的!
有趣的是，查看标准实现(我的无线程MinGW-w64上缺少gthr文件，但可以在github上找到它们)，结果发现它们几乎具有完全相同的代码。
除了我使用不带下划线且类型定义较少的单字符模板参数外，标准库使用动态分配。
哦，等等，动态分配状态，仅此而已!多么血腥明显。让我们作弊，看看他们到底在做什么。 (我对代码进行了编辑，以使其更易于阅读，删除了错误检查并遮盖了typedef，功能是相同的)。
class thread
{
...
struct _State { virtual void _M_run() = 0; };
template<typename _Callable> struct _State_impl : public _State
{
_Callable _M_func;
_State_impl(_Callable&& __f) : _M_func(std::forward<_Callable>(__f)) { }
void _M_run() { _M_func(); }
};
template<typename _Callable, typename... _Args> explicit thread(_Callable&& __f, _Args&&... __args)
{
_M_start_thread(_S_make_state(std::__bind_simple(std::forward<_Callable>(__f), std::forward<_Args>(__args)...)));
// _M_start_thread( unique_ptr<blah> (new blah(std::forward<>(blah))) ); // ---> OK, store state, and pass to _M_start_thread
}
void _M_start_thread(unique_ptr<_State> state, void (*)())
{
__gthread_create( ... &execute_native_thread_routine, state.get()); // __gthread_create == phtread_create
state.release();
}
};
在哪里:
extern "C"
{
static void* execute_native_thread_routine(void* __p)
{
thread::_State_ptr __t { static_cast<thread::_State*>(__p) };
__t->_M_run(); // courageous!
}
}
显然，标准实现是正确的。如果您有5％的程序可以运行amok的机会，那么数百万个每日用户中就有一个很早以前就注意到了。
但是，我不明白为什么是正确的，或者是为什么。如果您保证新产生的线程在原始线程返回之前运行，那当然可以工作。但是据我所知，pthreads或Win32都没有提供任何保证。
对我来说，方法看起来像:
unique_ptr pthread_create unique_ptr，释放状态这实际上就是标准实现“有效”的原因。它故意泄漏状态(感谢T.C.清理我将release与reset混淆了)。 execute_native_thread_routine(不同的线程)虽然我没有其他可靠的解决方案，但:
似乎有必要像等待事件计数/信号灯/条件变量(无论什么可用)之类，以确保线程已启动，不是吗？当然，这会使生成线程的效率非常低下。
有人可能会认为
shared_ptr可以解决问题。但是，如何通过系统库接口(interface)成功地传递shared_ptr，而该系统库接口(interface)则采用void*并将原始指针传递给其他线程呢？这不会飞。我几乎感觉就像只是在泄漏状态-不会在数百个线程中创建线程，而且泄漏的几十个字节可能并不明显。但是，然后，自动化分析工具将迎刃而解，如果进行了审核，审核员将非常非常聪明，可以指出这一非常危险的漏洞。
我曾经考虑过只在线程类中存储一个
std::function(似乎很合理，因为线程对象通常与该线程一样长的生命周期)。但是std::function想知道您在类范围内没有的类型...是否有更好(正确且可靠)的方法来做到这一点，而又不会丢失任何东西？
最佳答案
在花了半小时写了这个问题之后，我想我只是想出了令人尴尬的简单“Duh!”。本人对问题的回答类型:
Do not release the state in the calling thread at all. Instead, do it in the freshly created thread.
由于新线程必须(很明显)正在运行才能删除状态，因此不需要进一步的同步，也不需要传递智能指针。
为了防万一lambda抛出异常，为了安全起见，将原始指针包装到新线程一侧的
unique_ptr中并没有什么害处，如下所示:void* thr_prc(void* st) { std::unique_ptr<call_base>{static_cast<call_base*>(st)}->exec(); }
关于c++ - 可调用项，转发，右值和线程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39470352/