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

1) Der Ausführungsrichtlinientyp, der als eindeutiger Typ verwendet wird, um die Überladung paralleler Algorithmen zu unterscheiden und zu fordern, dass die Ausführung eines parallelen Algorithmus nicht parallelisiert werden darf. Die Aufrufe von Elementzugriffsfunktionen in parallelen Algorithmen, die mit dieser Richtlinie aufgerufen werden (üblicherweise 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 unterscheiden und anzuzeigen, dass die Ausführung eines parallelen Algorithmus parallelisiert werden darf. Die Aufrufe von Elementzugriffsfunktionen in parallelen Algorithmen, die mit dieser Richtlinie aufgerufen werden (üblicherweise angegeben als std::execution::par ), dürfen entweder im aufrufenden Thread oder in einem durch die Bibliothek implizit erstellten Thread zur Unterstützung der parallelen Algorithmusausführung ausgeführt werden. Alle derartigen Aufrufe, die im selben Thread ausgeführt werden, sind in unbestimmter Reihenfolge zueinander sequenziert. Wenn die durch std::thread oder std::jthread erstellten Ausführungs-Threads garantierte parallele Fortschrittsgarantien bieten, dann bieten die durch die Bibliothek erstellten Ausführungs-Threads parallele Fortschrittsgarantien. Andernfalls ist die bereitgestellte Fortschrittsgarantie implementierungsdefiniert. Hinweis: Parallele Fortschrittsgarantien stellen sicher, dass wenn ein Ausführungs-Thread einen Schritt macht, es irgendwann einen weiteren Schritt machen wird, was es Threads ermöglicht, kritische Abschnitte zu betreten und Sperren zu übernehmen, da der Thread, der die Sperre hält, irgendwann erneut eingeplant wird und in der Lage sein wird, diese freizugeben.

3) Der Ausführungsrichtlinientyp, der als eindeutiger Typ verwendet wird, um die Überladung paralleler Algorithmen zu unterscheiden und anzuzeigen, dass die Ausführung eines parallelen Algorithmus parallelisiert, vektorisiert oder über Threads hinweg 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 nicht spezifizierten 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 jene, die von der Standardbibliothek zur Synchronisation spezifiziert sind, einschließlich derer von std::atomic und anderen Nebenläufigkeitsprimitive. Wenn die durch std::thread oder std::jthread erstellten Ausführungs-Threads garantierte parallele Fortschrittsbedingungen bieten, dann bieten die durch die Bibliothek erstellten Ausführungs-Threads schwache parallele Fortschrittsgarantien. Andernfalls ist die bereitgestellte Fortschrittsgarantie die des Threads, der den parallelen Algorithmus aufruft. Hinweis: Schwache parallele Fortschrittsgarantien stellen sicher, dass einer der Ausführungs-Threads, die einen Schritt gemacht haben, irgendwann einen weiteren Schritt machen wird, was Threads nicht erlaubt, in kritische Abschnitte einzutreten oder Sperren zu übernehmen, da der Thread, der die Sperre hält, möglicherweise nicht erneut eingeplant wird, bis ein Thread, der versucht, die Sperre zu übernehmen, beendet wurde.

4) Der Ausführungsrichtlinientyp, der als eindeutiger Typ verwendet wird, um die Überladung paralleler Algorithmen zu unterscheiden und anzuzeigen, dass die Ausführung eines parallelen Algorithmus vektorisiert werden kann, z.B. auf einem einzelnen Thread unter Verwendung von Befehlen, die auf mehrere Datenelemente gleichzeitig 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); // Fehler: Datenwettlauf
});

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) { } // Fehler: setzt Ausführungsreihenfolge voraus
});

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; // korrekt
});

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); // Fehler: lock_guard-Konstruktor ruft m.lock() auf
    ++x;
});