параллельные алгоритмы (execution policies)parallel algorithms (execution policies)

C++17 добавляет к большинству алгоритмов <algorithm>/<numeric> перегрузку с execution policy первым аргументом — значением одного из трёх тегов пространства имён std::execution: seq (последовательно, но явно помечено как разрешённое к пересмотру реализацией), par (разрешено выполнить на нескольких потоках) и par_unseq (разрешено параллелить и векторизовать — например, SIMD-инструкциями внутри одного потока). Сам алгоритм — тот же самый по интерфейсу и результату, меняется только то, что реализация вправе распределить работу иначе.C++17 adds to most <algorithm>/<numeric> algorithms an overload with an execution policy as the first argument — a value of one of three tags in the std::execution namespace: seq (sequential, but explicitly marked as open to reconsideration by the implementation), par (allowed to run on multiple threads), and par_unseq (allowed to parallelize and vectorize — e.g. with SIMD instructions within a single thread). The algorithm itself stays the same in interface and result — only the implementation's freedom to distribute the work differs.

const auto n = v.size();
const auto mid = v.begin() + n / 2;
std::thread t1([&] { std::sort(v.begin(), mid); });
std::thread t2([&] { std::sort(mid, v.end()); });
t1.join(); t2.join();
std::inplace_merge(v.begin(), mid, v.end());
// вручную: разбиение диапазона, join, слияние — и это только для 2 потоков// manual: range splitting, join, merge — and this is only for 2 threads

#include <execution>
std::sort(std::execution::par, v.begin(), v.end());
// та же сигнатура std::sort, но стратегию параллелизации выбирает библиотека// the same std::sort signature, but the parallelization strategy is the library's choice

Распараллеливание стандартных алгоритмов долго оставалось задачей, которую стандартная библиотека не решала сама:Parallelizing standard algorithms had long remained a task the standard library didn't solve itself:

#include <execution>
#include <algorithm>
#include <numeric>

std::sort(std::execution::par, v.begin(), v.end());

// par_unseq — параллельно и векторизуемо: операция не должна// par_unseq — parallel and vectorizable: the operation must not
// иметь побочных эффектов, зависящих от порядка вызовов// have side effects that depend on call order
std::for_each(std::execution::par_unseq, v.begin(), v.end(),
              [](double& x) { x = x * x; });

// reduce — параллельная версия accumulate (сумма не гарантированно// reduce — the parallel version of accumulate (the sum isn't
// вычисляется в порядке элементов — операция должна быть ассоциативна)// guaranteed to be computed in element order — the op must be associative)
double total = std::reduce(std::execution::par, v.begin(), v.end(), 0.0);

Фокус этой страницы — именно на алгоритмах. Как устроены сами примитивы синхронизации под капотом (mutex, atomic, memory order, lock-free структуры) разобрано отдельно и глубже в cpp_concurrency.md — если после execution policies возникает вопрос "а что, если операция внутри алгоритма разделяет состояние между вызовами", ответ там же: нужна та же дисциплина atomics/mutex, что и в ручном многопоточном коде, execution policy сама по себе от гонок не защищает.This page's focus is specifically on algorithms. How the synchronization primitives themselves work underneath (mutex, atomic, memory order, lock-free structures) is covered separately and in more depth in cpp_concurrency.md — if after execution policies the question arises "what if the operation inside the algorithm shares state across calls," the answer lives there too: the same atomics/mutex discipline as in manual multithreaded code is required, an execution policy by itself doesn't protect against races.

Дальнейшее развитие этой же идеи — "декларативно описать асинхронную/параллельную работу и оставить исполнение планировщику" — продолжается моделью senders/receivers, готовящейся как std::execution в C++26: это более общий и композируемый механизм, чем execution policies алгоритмов C++17, но решает родственную задачу.The further evolution of this same idea — "declaratively describe asynchronous/parallel work and leave execution to a scheduler" — continues with the senders/receivers model being prepared as std::execution for C++26: a more general and composable mechanism than C++17's algorithm execution policies, but addressing a related problem.

• cppreference — Execution policies
• WG21 P0024 — The Parallelism TS Should be Standardized