More intelligent std::async decision to make new thread

Ko Stoffelen k.stoffelen@cs.ru.nl
Tue Mar 14 10:24:00 GMT 2017


Sure, but then I'm back to managing my own thread pool, which I thought
that <future> tried to avoid. I should rephrase that question: is it
possible *for std::async* to make a more intelligent decision?

On 14-03-17 10:57, Periklis Tsirakidis wrote:
> Ko Stoffelen <k.stoffelen@cs.ru.nl> writes:
>
>> Hi,
>>
>> I have a bunch of tasks that I'd like to execute in parallel as fast as
>> possible. I'm using std::async for this purpose, without a launch
>> policy, which is then std::launch::async | std::launch::deferred by
>> default. Now if I understand correctly, the C++ standard leaves it to
>> the implementation how it should handle this launch policy. libstdc++
>> always first tries to create a new thread and only if that raises an
>> exception, the task is deferred.
>>
>> https://gcc.gnu.org/onlinedocs/gcc-6.1.0/libstdc++/api/a01298_source.html#l01716
>>
>> In practice, this could imply that I'm running >100 threads on 4 cores
>> and the OS is only switching tasks all the time, actually delaying the
>> computation. Is it possible to make a more intelligent decision at
>> runtime, based on, e.g., the number of cores or the current CPU load?
>>
>> Thanks,
>>
>> Ko
>>
> You could, ask std::thread::hardware_concurrency() before selecting a
> policy. For cpu load you need some library to ask for it, i think.
>
> jm2c,


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20170314/ee032af2/attachment.sig>


More information about the Libstdc++ mailing list