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.
