<future> -Funktionen

  • Artikel

async
future_category
make_error_code
make_error_condition
swap|

async

Stellt einen asynchronen Anbieter dar.

template <class Fn, class... ArgTypes>
future<typename result_of<Fn(ArgTypes...)>::type>
    async(Fn&& fn, ArgTypes&&... args);

template <class Fn, class... ArgTypes>
future<typename result_of<Fn(ArgTypes...)>::type>
    async(launch policy, Fn&& fn, ArgTypes&&... args);

Parameter

policy
Ein launch-Wert.

Hinweise

Definitionen von Abkürzungen:

Abkürzung Beschreibung
dfn Das Ergebnis des Aufrufs von decay_copy(forward<Fn>(fn)).
dargs Die Ergebnisse des Aufrufs von decay_copy(forward<ArgsTypes>(args...)).
Ty Der result_of<Fn(ArgTypes...)>::type-Typ.

Die erste Vorlagenfunktion gibt async(launch::any, fn, args...) zurück.

Die zweite Funktion gibt ein future<Ty> Objekt zurück, dessen zugeordneter asynchroner Zustand ein Ergebnis zusammen mit den Werten dfn und dargs einem Threadobjekt enthält, um einen separaten Thread der Ausführung zu verwalten.

Sofern es sich nicht decay<Fn>::type um einen anderen Typ als "Start" handelt, nimmt die zweite Funktion nicht an der Überladungsauflösung teil.

Der C++-Standard gibt an, dass sich die Funktion, wenn die Richtlinie lautet launch::async, so verhält, als ob das aufrufbare Objekt in einem neuen Thread aufgerufen wird. Dies bedeutet, dass die Implementierung in der Regel zu einem neuen Thread führt, andere Mechanismen verwenden kann, um ein entsprechendes Verhalten zu erzielen. Die Microsoft-Implementierung entspricht derzeit jedoch nicht genau diesem Verhalten. Sie ruft Threads aus dem Windows ThreadPool ab, die einen recycelten Thread anstelle eines neuen Threads bereitstellen können. Dies bedeutet, dass die launch::async Richtlinie effektiv implementiert wird.launch::async|launch::deferred Eine weitere Auswirkung der ThreadPool-basierten Implementierung besteht darin, dass keine Garantie dafür besteht, dass threadlokale Variablen zerstört werden, wenn der Thread abgeschlossen ist. Wenn der Thread wiederverwendet und einem neuen Aufruf asyncbereitgestellt wird, sind die alten Variablen weiterhin vorhanden. Es wird empfohlen, die Verwendung von threadlokalen Variablen mit async.

Wenn policylaunch::deferred ist, wird von der Funktion der assoziierte asynchronen Zustand als das Enthalten einer verzögerten Funktion markiert, und sie wird zurückgegeben. Der erste Aufruf einer funktion ohne Zeit, die wartet, bis der zugeordnete asynchrone Zustand bereit ist, ruft die verzögerte Funktion durch Auswerten INVOKE(dfn, dargs..., Ty)auf.

In allen Fällen ist der zugeordnete asynchrone Zustand des future Objekts erst bereit, wenn die Auswertung INVOKE(dfn, dargs..., Ty) abgeschlossen ist, entweder durch Auslösen einer Ausnahme oder durch zurückgeben. Das Ergebnis des zugeordneten asynchronen Zustands ist eine Ausnahme, wenn eine ausgelöst wurde, oder der Wert, den die Auswertung zurückgibt.

Hinweis

Für einen future– oder das letzte shared_future– das an eine Aufgabe angefügt ist, die mit einer Aufgabe gestartet wurde std::async, blockiert der Destruktor, wenn die Aufgabe nicht abgeschlossen wurde. Das heißt, er blockiert, wenn dieser Thread noch nicht aufgerufen .get() wurde oder .wait() und die Aufgabe noch ausgeführt wird. Wenn ein future-Element, das von std::async erhalten wurde, außerhalb des lokalen Bereich verschoben wird, muss beim Schreiben von anderem Code, bei dem es verwendet wird, beachtet werden, dass der Destruktor möglicherweise blockiert, damit der Freigabezustand in den Bereitschaftszustand wechseln kann.

Die Pseudofunktion INVOKE ist definiert in <functional>.

Microsoft-spezifisch

Wenn die übergebene Funktion asynchron ausgeführt wird, wird sie im Windows-Threadpool ausgeführt. Weitere Informationen finden Sie unter Threadpools. Die Anzahl der gleichzeitigen Threads ist auf den Threadpoolstandard beschränkt, bei dem es sich um 500 Threads handelt.

Vor Windows 11 und Windows Server 2022 waren Anwendungen standardmäßig auf eine einzelne Prozessorgruppe mit höchstens 64 logischen Prozessoren beschränkt. Dadurch wird die Anzahl der gleichzeitig ausgeführten Threads auf 64 beschränkt. Weitere Informationen finden Sie unter Prozessorgruppen.

Ab Windows 11 und Windows Server 2022 verfügen Prozesse und deren Threads über Prozessoraffinitäten, die standardmäßig alle Prozessoren im System und mehrere Gruppen auf Computern mit mehr als 64 Prozessoren umfassen. Der Grenzwert für die Anzahl gleichzeitiger Threads ist nun die Gesamtanzahl der logischen Prozessoren im System.

future_category

Gibt einen Verweis auf das error_category-Objekt zurück, das Fehler bestimmt, die future-Objekten zugeordnet werden.

const error_category& future_category() noexcept;

make_error_code

Erstellt ein error_code-Objekt zusammen mit dem error_category-Objekt, mit dem zukünftige Fehler bestimmt werden.

inline error_code make_error_code(future_errc Errno) noexcept;

Parameter

Errno
Ein future_errc Wert, der den gemeldeten Fehler identifiziert.

Rückgabewert

error_code(static_cast<int>(Errno), future_category());

make_error_condition

Erstellt eine error_condition Kombination mit dem error_category Objekt, das Fehler kennzeichnet future .

inline error_condition make_error_condition(future_errc Errno) noexcept;

Parameter

Errno
Ein future_errc Wert, der den gemeldeten Fehler identifiziert.

Rückgabewert

error_condition(static_cast<int>(Errno), future_category());

swap

Tauscht den zugeordneten asynchronen Zustand eines promise-Objekts mit dem des anderen aus.

template <class Ty>
void swap(promise<Ty>& Left, promise<Ty>& Right) noexcept;

template <class Ty, class... ArgTypes>
void swap(packaged_task<Ty(ArgTypes...)>& Left, packaged_task<Ty(ArgTypes...)>& Right) noexcept;

Parameter

Left
Das linke promise-Objekt.

Right
Das rechte promise-Objekt.

Siehe auch

<future>