可调用,转发,右值和线程

Question

如何转发可能是rvalue及其(可变参数)参数的可调用对象,以便对待生成的线程100%正确且可靠？

我的猜测是答案是"等待条件变量",但我想确定.

我为什么这么问？

我有一个homebrewn线程实现,几十年来可靠地工作,很久以前std::thread就存在了.它仍然可以正常工作.现在我们确实有std::thread一段时间(或多或少,那就是......由于依赖于gthr/pthreads,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

嗯,这很有趣.怎么会这样？甚至没有足够的代码可能会出现严重故障.转发通用引用,使用指向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. release unique_ptr,deallocate state 这实际上是标准实现"工作"的原因.它故意泄露国家(感谢TC的清理,我感到困惑release与reset).
4. 最终运行execute_native_thread_routine(不同的线程)
5. 祈祷

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

1. 动态分配状态
2. 将指针传递给pthread_create
3. 收集内裤
4. ???
5. 安全释放国家
6. 利润!!!

看起来好像线程已经启动,似乎需要等待一个eventcount/semaphore/condition变量(无论什么是可用的),不是吗？当然,这会使产卵线程效率低下.

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

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

我曾考虑过只是std::function在线程类中存储一个(看起来很合理,因为线程对象通常和线程一样长).但是std::function想知道你在课堂范围内没有的类型......

有没有更好的(正确的,可靠的)这样做的方式,那就是没有可能在途中丢失一些东西？

Answer 1

在花了半个小时写了这个问题之后，我想我刚刚弄清楚了那个令人尴尬的简单“呃！” 我自己对问题的回答类型：

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

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

unique_ptr为了防止 lambda 抛出异常，将原始指针包装到新线程端的a 中也没有什么坏处，如下所示：

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