[cpp-threads] Asynchronous Execution Issues

Anthony Williams anthony at justsoftwaresolutions.co.uk
Tue Apr 28 11:33:21 BST 2009


At Tue 28 Apr 2009 02:08:22 BST, Lawrence Crowl <Lawrence at Crowl.org> wrote:

> How about a fourth option?
>
>     Add a three more "set" functions to std::promise (or an
>     additional parameter) that provide the additional semantics
>     that is_ready on the corresponding future will not be true
>     until the thread calling the promise has terminated.
>
> Practically, this means that the promise::set... will need to
> save the thread handle within the shared storage so that the
> ...future::wait... can join with the thread?

That's an interesting idea. So code that wanted the future to be ready  
when the thread finished would look something like:

some_promise.set_value(some_value,std::wait_for_this_thread);

The same could be applied to the packaged_task constructor.

std::packaged_task<int()> task(some_function,std::wait_for_this_thread);

Hmm. What if you ran your task on a thread other than that which  
constructed it? We can't add an extra parameter to the function call  
operator, since that passes it's arguments on to the contained function.

An alternative for packaged task is to have std::thread treat it  
specially, so if you pass a std::packaged_task to the thread  
constructor then the future becomes ready when the thread finishes.  
This would disallow simple wrappers around a packaged_task though.

I think I prefer the callback on thread completion (after thread_local  
destruction).

Anthony
-- 
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library   | http://www.stdthread.co.uk
Custom Software Development         | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK





More information about the cpp-threads mailing list