C++ Execution policy not working with std::map

user_5076854 0
Viewed 112

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 ?

execution c++
1 Answers

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.

user_26108100
Related