[cpp-threads] Asynchronous Function Proposal

[Pablo Halpern]

I have been silent on this discussion for a long time, partly because 
I've been extremely busy preparing and presenting a course on parallel 
programming.  I apologize if any of what I'm about to say should have 
been said earlier.

On 6/15/2009 8:08 PM, Lawrence Crowl wrote:
> On 6/13/09, Herb Sutter <hsutter at microsoft.com> wrote:
>   
>>   - The wording for the first policy still says "in a new thread,"
>>   which prevents the implementation from caching threads in any way
>>   (including the highly desirable option of running on a thread
>>   pool). It should say "in another thread."
>>     
>
> N2880 says why allowing thread caching is not feasible.  We can do
> caching when we have thread pools, but I don't believe that we can
> do so until then.
>
> BTW, the OS can still cache threads underneath, but it still has
> to destroy and reconstruct the thread-local variables.
>   
On this point, I must strongly agree with Lawrence.  I sympathize with 
the desire to make the async() facility more friendly for creating 
fine-grained parallelism, but I don't think we can do that in C++0x, for 
several reasons:

1. The parallel-programming trend is just now heating up.  If we try to 
standardize sophisticated facilities for parallel programming, we are 
certain to get it wrong.  Although Cilk, TBB, OpenMP and others have 
been around for a while, we are just now beginning to get wide-spread 
use of these tools on real multicore computers.  Let the market sort out 
the best technologies and practices before we try to enshrine something 
in the standard.

2. What we have in C++0x is a threading library, not a 
parallel-programming library.  If it can be used as a platform for a 
parallelism library, great, but we should not try to throw one 
parallel-programming trick into the mix in isolation.  TBB already 
exists and is much more powerful than async().  For anything other than 
the most trivial types of parallelism, I would tell people to use TBB or 
Cilk++, rather than async.

3. I don't think async() will actually work as a general fork-join tool 
without a LOT more work.  In particular, the fact that it returns a 
future whose lifetime is not tightly constrained and which can be moved 
not only out of the caller's scope, but onto another thread makes me 
wonder if this kind of concurrency is composable.  At Cilk Arts, we have 
done a lot of work to make sure our parallel constructs compose 
cleanly.  An equal amount of work would be needed for a standard facility.

These points aside, I think async() is a useful facility, within 
limits.  The way Lawrence has specified it, it meets the requirements of 
UK-182 and the Kona compromise without being overly ambitious.  It is 
even usable for simple parallelization and leaves room for a future 
thread-pool extension.  If it can be implemented on top of a 
work-stealing scheduler, so much the better, but I wouldn't hold my breath.

I have some opinions on the other issues (argument order, time of call 
for synchronous calls, etc.), but they are mild in comparison to this 
major issue and I will described them in a separate message.

Thanks,
- Pablo