[cpp-threads] Asynchronous Execution Issues

[Lawrence Crowl]

On 4/24/09, Oliver Kowalke <oliver.kowalke at gmx.de> wrote:
> I'm currently implementing a library (boost.task formaly known
> as boost.threadpool) which implements this kind of functionality.

Thanks for the heads up.

>  - 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).

And what happens to objects of thread storage duration?

> 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.

Hm.  Is the mapping reversed?  In my proposal, the caching_async
need not join after completion, but may place the thread in a pool
for reuse later.

> Am Friday 24 April 2009 22:39:11 schrieb Lawrence Crowl:

Hm.  Your mailer seems incompletely localized.  Shouldn't that
be Freitag?

> > 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?

-- 
Lawrence Crowl