std::execution::sequenced_policy, std::execution::parallel_policy, std::execution::parallel_unsequenced_policy, std::execution::unsequenced_policy

class sequenced_policy { /* unspecified */ };

class parallel_policy { /* unspecified */ };

class parallel_unsequenced_policy { /* unspecified */ };

class unsequenced_policy { /* unspecified */ };

1) Der Ausführungsrichtlinientyp, der als eindeutiger Typ verwendet wird, um die Überladung paralleler Algorithmen zu disambiguieren und zu verlangen, dass die Ausführung eines parallelen Algorithmus nicht parallelisiert werden darf. Die Aufrufe von Elementzugriffsfunktionen in parallelen Algorithmen, die mit dieser Richtlinie aufgerufen werden (normalerweise angegeben als std::execution::seq), sind im aufrufenden Thread unbestimmt sequenziert.

2) Der Ausführungsrichtlinientyp, der als eindeutiger Typ verwendet wird, um die Überladung paralleler Algorithmen zu disambiguieren und anzuzeigen, dass die Ausführung eines parallelen Algorithmus parallelisiert werden kann. Die Aufrufe von Elementzugriffsfunktionen in parallelen Algorithmen, die mit dieser Richtlinie aufgerufen werden (normalerweise angegeben als std::execution::par), dürfen entweder im aufrufenden Thread oder in einem Thread ausgeführt werden, der implizit von der Bibliothek zur Unterstützung der parallelen Algorithmusausführung erstellt wurde. Solche Aufrufe, die im selben Thread ausgeführt werden, sind gegeneinander unbestimmt sequenziert. Wenn die von std::thread oder std::jthread erstellten Ausführungsthreads nebenläufige Fortschrittsgarantien bieten, dann bieten die von der Bibliothek erstellten Ausführungsthreads parallele Fortschrittsgarantien. Andernfalls ist die bereitgestellte Fortschrittsgarantie implementierungsdefiniert. Hinweis: Parallele Fortschrittsgarantien bedeuten, dass ein Ausführungsthread, der einen Schritt macht, irgendwann einen weiteren Schritt machen wird, sodass Threads in kritische Abschnitte eintreten und Sperren übernehmen können, da der Thread, der die Sperre hat, irgendwann wieder eingeplant wird und sie freigeben kann.

3) Der Ausführungsrichtlinientyp, der als eindeutiger Typ verwendet wird, um die Überladung paralleler Algorithmen zu disambiguieren und anzuzeigen, dass die Ausführung eines parallelen Algorithmus parallelisiert, vektorisiert oder zwischen Threads migriert werden kann (z.B. durch einen Parent-Stealing-Scheduler). Die Aufrufe von Elementzugriffsfunktionen in parallelen Algorithmen, die mit dieser Richtlinie aufgerufen werden, dürfen in ungeordneter Weise in unspezifizierten Threads ausgeführt werden und sind innerhalb jedes Threads unsequenziert zueinander. Die Aufrufe von Elementzugriffsfunktionen in parallelen Algorithmen, die mit dieser Richtlinie aufgerufen werden, dürfen keine vektorisierungsunsicheren Operationen aufrufen, wie sie von der Standardbibliothek zur Synchronisation spezifiziert werden, einschließlich derer von std::atomic und anderen Nebenläufigkeitsprimitiven. Wenn die von std::thread oder std::jthread erstellten Ausführungsthreads nebenläufige Fortschrittsgarantien bieten, dann bieten die von der Bibliothek erstellten Ausführungsthreads schwach parallele Fortschrittsgarantien. Andernfalls ist die bereitgestellte Fortschrittsgarantie die des Threads, der den parallelen Algorithmus aufruft. Hinweis: Schwach parallele Fortschrittsgarantien bedeuten, dass einer der Ausführungsthreads, die einen Schritt gemacht haben, irgendwann einen weiteren Schritt machen wird, was es Threads nicht erlaubt, in kritische Abschnitte einzutreten oder Sperren zu übernehmen, da der Thread, der die Sperre hat, möglicherweise erst dann wieder eingeplant wird, wenn ein Thread, der versucht, die Sperre zu erlangen, beendet ist.

4) Der Ausführungsrichtlinientyp, der als eindeutiger Typ verwendet wird, um die Überladung paralleler Algorithmen zu disambiguieren und anzuzeigen, dass die Ausführung eines parallelen Algorithmus vektorisiert werden kann, z.B. auf einem einzelnen Thread unter Verwendung von Anweisungen, die auf mehreren Datenelementen operieren.

int a[] = {0, 1};
std::vector<int> v;
std::for_each(std::execution::par, std::begin(a), std::end(a), [&](int i)
{
    v.push_back(i * 2 + 1); // Error: data race
});

std::atomic<int> x {0};
int a[] = {1, 2};
std::for_each(std::execution::par, std::begin(a), std::end(a), [&](int)
{
    x.fetch_add(1, std::memory_order_relaxed);
    while (x.load(std::memory_order_relaxed) == 1) { } // Error: assumes execution order
});

int x = 0;
std::mutex m;
int a[] = {1, 2};
std::for_each(std::execution::par, std::begin(a), std::end(a), [&](int)
{
    std::lock_guard<std::mutex> guard(m);
    ++x; // correct
});

int x = 0;
std::mutex m;
int a[] = {1, 2};
std::for_each(std::execution::par_unseq, std::begin(a), std::end(a), [&](int)
{
    std::lock_guard<std::mutex> guard(m); // Error: lock_guard constructor calls m.lock()
    ++x;
});