Const-ness affecting concurrent algorithms?

75 views Asked by At

Are there any examples of the absence or presence of const affecting the concurrency of any C++ Standard Library algorithms or containers? If there aren't, is there any reason using the const-ness in this way is not permitted?

To clarify, I'm assuming concurrent const access to objects is data-race free, as advocated in several places, including GotW 6.

By analogy, the noexcept-ness of move operations can affect the performance of std::vectors methods such as resize.

I skimmed through several of the C++17 concurrent Algorithms, hoping to find an example, but I didn't find anything. Algorithms like transform don't require the unary_op or binary_op function objects to be const. I did find for_each takes a MoveConstructible function object for the original, non execution policy version, and take a CopyConstructible function object for the C++17 execution policy version; I thought this might be an example where the programmer was manually forced to select one or the other based on if the function object could be safely copied (a const operation)... but at the moment I suspect this requirement is just there to support the return type (UnaryFunction vs. void).

0

There are 0 answers