User account creation filtered due to spam.

Bug 51617 - [C++0x] async(f) isn't.
Summary: [C++0x] async(f) isn't.
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.7.0
: P3 enhancement
Target Milestone: 6.0
Assignee: Jonathan Wakely
URL:
Keywords:
Depends on:
Blocks: 49204
  Show dependency treegraph
 
Reported: 2011-12-19 05:02 UTC by Dave Abrahams
Modified: 2015-05-05 01:59 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-12-19 00:00:00


Attachments
demonstration (634 bytes, application/octet-stream)
2011-12-19 05:02 UTC, Dave Abrahams
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Abrahams 2011-12-19 05:02:13 UTC
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
Comment 1 Dave Abrahams 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 ]
Comment 2 Jonathan Wakely 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!)
Comment 3 Jonathan Wakely 2011-12-19 10:49:41 UTC
confirming as an enhancement request
Comment 4 Dave Abrahams 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.
Comment 5 Jonathan Wakely 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 :)
Comment 6 Jakub Jelinek 2013-03-22 14:44:15 UTC
GCC 4.8.0 is being released, adjusting target milestone.
Comment 7 Jonathan Wakely 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
Comment 8 Jakub Jelinek 2014-04-22 11:36:25 UTC
GCC 4.9.0 has been released
Comment 9 Jakub Jelinek 2014-07-16 13:29:10 UTC
GCC 4.9.1 has been released.
Comment 10 Jonathan Wakely 2015-01-30 10:35:01 UTC
Not happening this release either.
Comment 11 torvald 2015-04-27 13:38:26 UTC
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().
Comment 12 Jonathan Wakely 2015-05-05 01:57:19 UTC
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
Comment 13 Jonathan Wakely 2015-05-05 01:59:58 UTC
Fixed on trunk.