[Bug libstdc++/51618] synchronous futures are slow

["dave at boostpro dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618

--- Comment #2 from Dave Abrahams <dave at boostpro dot com> 2011-12-19 12:11:33 UTC ---
on Mon Dec 19 2011, "redi at gcc dot gnu.org" <gcc-bugzilla-AT-gcc.gnu.org>
wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618
>
> --- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-19 11:51:52 UTC ---
> Could you expand on what you mean by "no attached synchronization"?

There's not much to say.  "Attached" is probably superfluous.

> If a global future visible to all threads stores a deferred function then it
> still needs synchronization to ensure only one thread can invoke the deferred
> function and that other threads will wait for it to complete.

I'm confused.  IIUC even shared_futures aren't supposed to be accessed
concurrently from multiple threads.  Why would multiple threads be
accessing a single plain future?

> std::async is not meant to be the fastest or most flexible solution, it's meant
> to be a simple way to exploit a limited amount of concurrency, without breaking
> the Kona compromise.  Better solutions are suitable for TR2.

I know it's not supposed to be the fastest, but it seems as though it
can be optimized.  If a trivial parallel mergesort using async can run
3x faster than it does now, that's a huge win for users: it means they
can put off trying complex and/or dangerous alternatives.