Created attachment 26132 [details] 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
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 ]
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!)
confirming as an enhancement request
(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.
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 :)
GCC 4.8.0 is being released, adjusting target milestone.
I didn't get this done for 4.8 and it would be too invasive for 4.8.1 so adjusting milestone
GCC 4.9.0 has been released
GCC 4.9.1 has been released.
Not happening this release either.
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().
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
Fixed on trunk.