The std::async
has two overloads, one of them makes the parameter std::launch policy
explicit while the other omits this parameter. The policy is a bitmask, so both launch::async|launch::deferred
may be specified (or you may avoid the policy using the function that omits this parameter). Under the hood the policy is selected automatically in this case, and the choice is not guaranteed. I wonder what should be the reason of using this "unknown" policy.
First of all, you shouldn't use this policy together with wait
functions: you may just get the future_status::deferred
response to discover that calling this function was useless. Next, you may use default policy if you plan just to get
the value on some point, but I see no reason to leave this selection on the system/library implementation, because even std::launch::async
may optimize the number of threads used for the execution. Anyway, the actual explicitly selected policy strongly impacts the pattern of usage, and that is very strange to use the function that hides this information by design.
What may be a practical use case when someone would prefer to leave the policy selection to the system?
std::launch::deferred
and MSVC always prefersstd::launch::async
, I would use an explicit policy to avoid ambiguity, otherwise I guess that I don't need thestd::async
at all. – Rosati