[cpp-threads] Asynchronous Function Proposal

[Anthony Williams]

Lawrence Crowl wrote:
> Always invoke the function in a new thread.
>     Note that we do not choose "another thread" because of the problems
>     described in N2880
>     <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2880.html>.
>     In particular, one cannot use thread pools without exposing them to
>     the programmers. This pint has not reached consensus. 

s/pint/point/

Note that choosing "a new thread" does not get round the issues from 
N2880, as the future may be discarded without waiting (as you highlight 
below), in which case you still essentially have a detached thread.

>     * Work launched asynchronously must necessarily transmit exceptions
>       arising from the work to the point the value is requested. To
>       avoid exception handling code in two places, we choose exclusively
>       the one place we must have.

I think that's a red herring. If the work is executed synchronously at 
the point of the async call, the return value or any exception thrown 
should be stored in the future as always.

>     * Work stealing implementations will be ineffective if the async
>       functions have already committed to an eager serial execution.

If you've explicitly chosen serial execution this is another red herring 
--- it only matters in the case that the user selected the 
"implementation chooses" policy.

> Eager semantics seem more natural when programmers think of "waiting to 
> use the return value". 

They also seem more natural when you select an "execute synchronously" 
policy. It seems surprising to me that explicitly specifying such a 
policy would NOT execute the work immediately. Also, given a policy of 
"must_be_called", it would be surprising if the work did not actually 
get called (because the future was discarded without waiting)!

>     * An implementation of |std::unique_future| that can track the task
>       will necessarily impose an implementation burden on other uses of
>       |std::unique_future|.

The cost to other uses does not have to be high: a single flag check or 
virtual function call inside wait() and get() should suffice.

>     |~joining_future();|
> 
>         /Effects:/ destroys |*this| and its associated state if no other
>         object refers to that. If the invocation has been deferred, the
>         invocation is not executed.

What about if the invocation was deferred, but has already 
started/completed?

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