Callables，forwarding，rvalues和threads

Question

如何转发可能是rvalue及其（可变参数）参数的可调用对象，因此对于待生成的线程，执行是100％正确且可靠的？

我的猜测是答案是＆＃34;等待条件变量＆＃34;，但我想确定。

为什么我问这个？

我有一个homebrewn线程实现，在std::thread存在之前很久就可以100％可靠地工作了几十年。它仍然可以正常工作。现在我们已经有std::thread一段时间了（或多或少，就是...... MinGW类型的发行版对线程的支持并不是很好，这要归功于依赖于gthr / pthreads，遗憾的是，我绝对需要支持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

嗯，这很有趣。怎么会这样？甚至没有足够的代码可能会出现严重故障。转发了通用引用，使用指向params的指针生成线程，所有内容都看起来完全无辜。

除了以外，如果另一个线程尚未在spawn_thread返回时启动（显然在我的系统上发生过20次一次）。 因为在这种情况下，新线程将尝试读取您刚刚发布和覆盖的状态。

标准库方法

让我们看看标准库是如何做到的！

有趣的是，看看标准实现（我的无线程可用MinGW-W64上缺少gthr文件，但它们可以在github上找到），事实证明它们的代码几乎完全相同。 除了我使用没有下划线和更少typedef的单字符模板参数，标准库使用动态分配。

哦等等，动态分配状态，这就是它！多么血腥明显。让我们作弊，看看他们究竟在做什么。 （我已编辑代码以使其更易于阅读，删除错误检查并模糊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％的机会让你的程序无法运行，那么很久以前就会有几百万用户注意到这一点。

但是，我不明白为什么它是正确的，或者如何。如果你保证新生成的线程在原始线程返回之前运行，那当然会有效。但据我所知，pthreads和Win32，以及任何其他线程API都没有提供这种保证。

对我而言，方法如下：

1. 动态分配状态，分配给unique_ptr
2. 将原始指针传递给状态为pthread_create
3. 发布unique_ptr，解除分配状态 这实际上是标准实施＆＃34;工作的原因＆＃34;。它故意泄漏状态（感谢T.C.清理我将release与reset混淆了。）
4. 最终运行execute_native_thread_routine（不同的主题）
5. <击>祈祷

虽然我没有看到其他可靠的解决方案：

1. 动态分配状态
2. 将指针传递给pthread_create
3. collect underpants
4. ???
5. 安全释放状态
6. 利润!!!

似乎有必要等待一个eventcount / semaphore / condition变量（无论什么是可用的）来确保线程已经启动，不是吗？当然，这会使产卵线程效率低下。

有人可能认为shared_ptr可以解决问题。但是，如何通过系统库接口成功传递shared_ptr，该接口接受void*并将该原始指针传递给另一个线程？这不会飞。

我几乎觉得只是泄漏状态 - 线程不是以数百个形式创建的，泄漏的几十个字节可能并不明显。但是，自动化分析工具会对它进行抨击，如果进行审核，审核员将非常非常聪明地指出这种非常危险的泄漏。

我曾想过只是在线程类中存储std::function（看起来很合理，因为线程对象通常与线程一样长）。但std::function想知道你在课堂范围内没有的类型......

有没有更好的（正确的，可靠的）这样做的方式，那可能不会在途中丢失一些东西？

Answer 1

在写完这个问题花了半个小时后，我想我只想出了令人尴尬的简单“杜！”问题的答案类型我自己：

  

根本不要在调用线程中释放状态。相反，在新创建的线程中执行它。

由于新线程必须（非常明显地）运行才能删除状态，因此不需要进一步同步，也不需要传递任何智能指针。

对于lambda抛出的情况下的异常安全性，将原始指针包装到新线程端的unique_ptr并不会有什么坏处，如下所示：

void* thr_prc(void* st) { std::unique_ptr<call_base>{static_cast<call_base*>(st)}->exec(); }