[cpp-threads] Asynchronous Function Proposal

[Anthony Williams]

Boehm, Hans wrote:
> It sounds to me like Lawrence's proposal fundamentally would work,
> with one highly desirable change:  We do need to give the
> implementation the necessary leeway to run an async task at the point
> of call, so that it can throttle the number of async tasks when it
> becomes necessary for space reasons.  Possibly this could be another
> policy option, though it sounds to me like the most useful policy is
> 
> run sequentially at point of creation (if we have too many pending
> tasks), or run sequentially at point of request (if it didn't get
> stolen in the meantime), or run in a separate thread.

The simplest possible async function would just say that these were the 
allowed possibilities, and require that the application cope with not 
knowing which would happen. I'm inclined to think that adding a policy 
to allow choice is overcomplicating this "simple" support. Such control 
and choice belongs in a more feature-rich parallel programming system, 
which hopefully will become part of TR2.

> It's unclear to me whether that means that exceptions should
> sometimes become visible at the point of async creation or not.  It
> may be that space-based throttling is rare enough that we can afford
> any extra overhead needed to defer the exception, though that's
> probably surprising in some cases.  Having to handle exception in two
> places also seems unfortunate.

I strongly feel that if the results of running the async task should be 
stored in the returned future *whenever* that task is run (including if 
it is run directly as part of the async call and is complete before the 
call to async returns). This includes any exceptions thrown. The only 
reason the async call itself should throw an exception is because the 
call itself failed (too many tasks, too many threads, not enough memory, 
whatever....) rather than anything to do with the behaviour of the task 
being run potentially asynchronously.

> Even if exceptions are handled only at the request point, we need to
> explicitly allow running the task earlier, since that's visible by
> other means.

Yes, if we intend to allow it (and I think we should) then it needs to 
be specified as permitted.

> I would still favor sticking with Lawrence's design that avoids
> (visibly) reusing threads for multiple tasks.  

I don't think we should specify whether or not the threads are reused. 
If we say threads *may* be reused, then the user cannot rely on anything 
(they may get a fresh thread or be the last task on a thread anyway) and 
it gives implementors greatest freedom.

If we don't allow thread reuse then you force implementations to spawn 
threads repeatedly. You also disallow task stealing, since effectively 
the only point of such a mechanism is that you already have a thread 
running that can steal the work.

> A more minimalist approach may be to support only the fully_threaded
> policy for now, but leave room for additional policies in the future.

Agreed. You can always add policies later either by adding an additional 
parameter to overloads, or by creating a new function with a new name.

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