[cpp-threads] Asynchronous Function Proposal

[Anthony Williams]

Beman Dawes wrote:
> On Sun, May 31, 2009 at 6:59 PM, Lawrence Crowl <Lawrence at crowl.org> wrote:
>> Future
>>
>> The proposal includes a new future type because it cannot provide the
>> full interface of the existing futures.
>>
>> * The value get must join with the thread performing the work to
>> ensure that all thread-local variables have been destroyed before
>> execution of code depending on the return value. Unfortunately, the
>> thread class has no timed join, so the async_future cannot support a
>> timed_wait.
>>
>> * The thread class has neither query to determine if the
>> thread has finished nor a try_join operation. Thus, one cannot
>> implement an is_ready query that includes the fact that all
>> thread-local variables have been destroyed.
>>
>> * Sequential execution
>> defers invocation of the work until the get call, which means that
>> the value versus exception result of a function is unknown until that
>> time. So, the has_value and has_exception queries cannot provide
>> meaningful results before then.
> 
> As Herb pointed out, this makes it look like we have serious problems
> with the current future interface and/or the current thread interface.
> I very much want to hear what Howard, Anthony, and others with a deep
> understanding of standard library threads/futures/promises have to say
> about these issues.

Just to address this particular point:

I don't think we need a new async_future: the current 
unique_future/shared_future set is fine. The problem is on the side of 
the code that *sets* the future value. As pointed out in N2880, there is 
  no way to ensure that the future is made ready *after* thread-local 
variables have been destroyed *if you stick to the public interface in 
the current standard*.

However, async would be a standard-library function, so can use 
implementation-specific magic to ensure that the thread-locals *are* 
destroyed before the future is made ready.

Using a special async_future type essentially says that the thread-local 
issue is insoluble. I still hope we can find a way to solve this problem 
that we can expose as part of the public interface to the C++0x thread 
library.

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