[Bug c++/51617] New: [C++0x] async(f) isn't.

[Bug c++/51617] New: [C++0x] async(f) isn't.

[dave at boostpro dot com]

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

             Bug #: 51617
           Summary: [C++0x] async(f) isn't.
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dave@boostpro.com


Created attachment 26132
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26132
demonstration

I am finding I have to explicitly pass a launch policy to get async to run
anything in a thread.  For example, when I time the attached with
-DFORCE_PARALLEL I get

/tmp/tst  81.54s user 0.23s system 628% cpu 13.001 total

and without it I get:

/tmp/tst  41.29s user 0.05s system 99% cpu 41.343 total

See also bug 49204

[Bug c++/51617] [C++0x] async(f) isn't.

[dave at boostpro dot com]

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

--- Comment #1 from Dave Abrahams <dave at boostpro dot com> 2011-12-19 05:11:20 UTC ---
I should add this (non-normative, but still) note from [futures.async]:

[ Note: If this policy is specified together with other policies, such as when
using a policy value of launch::async | launch::deferred, implementations
should defer invocation or the selection of the policy when no more concurrency
can be effectively exploited. — end note ]

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-19 10:43:22 UTC ---
Yes, this was an intentional choice (as I described in message
c++std-lib-30840) to ensure the system doesn't get killed by a fork bomb, e.g.
writing a parallel sort algorithm using async which launches a new thread for
every partition. I tried it, it wasn't pretty :)

At some point I will use getloadavg() or equivalent functionality to check the
system load and decide whether to launch a new thread or not, until then the
safer choice is to require a user to explicitly request it (then it's the
user's fault if they fork bomb their machine!)

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-12-19
             Blocks|                            |49204
     Ever Confirmed|0                           |1
           Severity|normal                      |enhancement

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-19 10:49:41 UTC ---
confirming as an enhancement request

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[dave at boostpro dot com]

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

--- Comment #4 from Dave Abrahams <dave at boostpro dot com> 2011-12-19 10:58:46 UTC ---
(In reply to comment #2)
> Yes, this was an intentional choice (as I described in message
> c++std-lib-30840) to ensure the system doesn't get killed by a fork bomb, e.g.
> writing a parallel sort algorithm using async which launches a new thread for
> every partition. I tried it, it wasn't pretty :)

Hey, cool; I tried it too.  I mean, when I discovered async wasn't async. :-)

> At some point I will use getloadavg() or equivalent functionality to check the
> system load and decide whether to launch a new thread or not, until then the
> safer choice is to require a user to explicitly request it (then it's the
> user's fault if they fork bomb their machine!)

Yeah, but in the meantime you could also just limit async() threads to
hardware_concurrency() using the technique shown in my attachment.  It wouldn't
necessarily guarantee good performance but it would be enough to prevent async
from fork bombing while still allowing some semi-intelligent amount of
parallelism.

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-19 11:13:25 UTC ---
That would require a global integer somewhere to count the threads, which would
probably have to be kept forever to maintain ABI compatibility.  If I had time
to implement a temporary semi-intelligent fix then I'd rather just do it
properly instead :)

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.0                       |4.8.1

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-22 14:44:15 UTC ---
GCC 4.8.0 is being released, adjusting target milestone.

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |redi at gcc dot gnu.org
                   |gnu.org                     |
   Target Milestone|4.8.1                       |4.9.0

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> 2013-03-23 15:01:34 UTC ---
I didn't get this done for 4.8 and it would be too invasive for 4.8.1 so
adjusting milestone

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.0                       |4.9.1

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.0 has been released

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.1                       |4.9.2

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.1 has been released.

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.2                       |4.10.0

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.0                         |6.0

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Not happening this release either.

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[torvald at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617

torvald at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |torvald at gcc dot gnu.org

--- Comment #11 from torvald at gcc dot gnu.org ---
ISO C++ SG1 was close to deprecating std::async for other reasons, but there
was too much objection to this from other parts of the committee; the main
concern was that there is no replacement for the functionality.  Even though
the executors proposal is still being discussed and not part of any published
TS yet, the parallelism TS V1 is being published.  Thus, I'm not sure whether
spending too much time is justified, given the potentially short-lived
importance of current async().

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Author: redi
Date: Tue May  5 01:56:47 2015
New Revision: 222793

URL: https://gcc.gnu.org/viewcvs?rev=222793&root=gcc&view=rev
Log:
        PR libstdc++/51617
        * include/std/future (async): Change default policy to launch::async.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/std/future

[Bug libstdc++/51617] [C++0x] async(f) isn't.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed on trunk.