[cpp-threads] Asynchronous Execution Issues (caching_async)

[Herb Sutter]

Just to repeat my $0.02 that I've been saying since the Kona meeting:

1. It is highly desirable to have an async() that is not guaranteed to run on a different thread, for exactly the reasons Hans mentioned -- enabling the new breed of work-stealing implementations that have significantly better performance and will be widespread in the next small number of years (Intel TBB, Java Fork/Join, Cilk++, and three Microsoft products (PPL for C++, TPL and PLINQ for .NET).

2. But semantically you also want I understand why it's also desirable to have an async()

Without #1, we don't support efficient parallel computation (at least, no longer competitive with current industry practice). Without #2, you don't support asynchrony/concurrency such as getting work off a GUI thread to run in the background. #1 can't be used for concurrency, and #2 can't efficiently be used for parallelism. That's why you want both, and the user needs to be able to spell both.

Herb


> You might still get acceptable results at sufficiently large
> granularity.  But this seems far more limited than Cilk.  And
> presumably Cilk was largely motivated by the inadequacy of this kind of
> solution.

> Doug may undesratnd the tradeoffs here a bit better.  But as far as I
> can tell, there would be a significant risk of standardizing something
> that's useless in the long run.