[cpp-threads] Asynchronous Execution Issues

[Oliver Kowalke]

Hello,

I'm currently implementing a library (boost.task formaly known as 
boost.threadpool) which implements this kind of functionality.

- second item:
launch_in_thread() (== std::caching_async()) returns a handle object which 
contain a smart pointer of boost::thread (==std::thread). If the last 
instance of this handle gets out of scope the custom destructor of smart 
pointer calls thread::join() on the thread object (releasing the thread).
BTW handle allows to interrupt the task executed by the thread and works as a 
async completion token (contains a future and exposes this interface).

- first:
launch_in_pool() would be equivalent to std::creating_async() passing the task 
into a threapool and returning a handle object too. But destroying a 
pool-internal-thread is not permitted. In this case cleaning up thread-local 
data (thread_specific_ptr) after execution of a task is a problem. Currently 
it is up to the user.

best regards,
Oliver


Am Friday 24 April 2009 22:39:11 schrieb Lawrence Crowl:
> At the Summit meeting I took the action item of producing a proposal
> for a simple asynchronous execution.  The idea was to facilities,
> with an API along the lines of:
>
>     auto x = std::creating_async( function1 );
>     auto y = std::caching_async( function2 );
>     ....
>     auto a = x.get();
>     auto b = y.get();
>
> The difference between the two is that creating_async would always
> create a new thread, while the caching_async is permitted to reuse
> threads.  The primary operational difference is that thread-local
> storage is reused in the latter case.
>
> There are a couple of issues that make the task more difficult than
> we thought at the time.  As a result, I have a couple of questions.
>
> First, consider the case of the caching_async.  Because the threads
> may persist, we need a handle on the list of threads so that we
> can inform a thread to die so that we destroy any thread-local
> variables before the global variables that they reference.  So, we
> start needing a manager object, and the whole facility is starting
> to look too much like a thread pool.  I don't feel as though I have
> a mandate to propose anything that looks like a thread pool.  Do
> you agree?
>
> Second, consider the case of the creating_async.  The problem here
> is a touch more subtle.  In particular, once the working thread has
> set its promise, it can start destroying thread-local variables.
> Unfortunately, we have no idea when that has or might happen.
> That thread could be stalled immediately after providing the value.
> The solution is to wait for thread termination before returning the
> value from the future.  This solution implies keeping the thread as
> part of the future so that we can wait.  We have no such mechanism.
> So, an asynchronous execution function needs another kind of future.
> Is such a future going beyond my mandate?