'C++ Execution policy not working with std::map
I have successfully used std::execution::par_unseq policy on ubuntu 20.04 with gcc 9. However I encounter a strange behavior where it didn't work with maps but worked with vectors
Example 1:
typedef std::map<std::string, std::vector<std::shared<Foo>>> ProblemsType;
ProblemsType values;
FillValues(values);
std::for_each(std::execution::par_unseq, values.begin(), values.end(), [](ProblemsType::value_type value) {
// Do something
}
Example 2:
typedef std::map<std::string, std::vector<std::shared<Foo>>> ProblemsType;
ProblemsType values;
FillValues(values);
std::vector<std::pair<std::string>, std::vector<std::shared<Foo>>> valuesAsVector;
FillVectorWithMapValues(valuesAsVector, values);
std::for_each(std::execution::par_unseq, valuesAsVector.begin(), valuesAsVector.end(), [](std::pair<std::string>, std::vector<std::shared<Foo>> value) {
// Do something
}
#1 doesn't work but #2 does. I checked by watching cpu usage with htop and saw all core used (and several thread spwaned) with #2. With #1 only one core was used.
I checked and std::map::iterator is a LegacyBidirectionalIterator that satisfies LegacyForwardIterator.
Is there anything special with std::map preventing the use of execution policy par_unseq ?
Solution 1:[1]
Is there anything special with std::map preventing the use of execution policy par_unseq ?
You weren't prevented from using par_unseq, presumably the implementation chose not to do anything different from the non-policy overload.
It's then a quality-of-implementation issue as to whether the implementation does anything different with the extra freedom the policy gives it.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Caleth |
