Partager via


fonctions<future>

async
future_category
make_error_code
make_error_condition
swap|

async

Représente un fournisseur asynchrone.

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);

Paramètres

policy
Une valeurlaunch.

Notes

Définitions des abréviations :

Abréviation Description
dfn Résultat de l’appel de decay_copy(forward<Fn>(fn)).
dargs Résultats des appels decay_copy(forward<ArgsTypes>(args...)).
Ty Le type result_of<Fn(ArgTypes...)>::type.

La première fonction de modèle retourne async(launch::any, fn, args...).

La deuxième fonction retourne un future<Ty> objet dont l’état asynchrone associé contient un résultat avec les valeurs et dargs dfn un objet thread pour gérer un thread d’exécution distinct.

Sauf s’il s’agit decay<Fn>::type d’un type autre que le lancement, la deuxième fonction ne participe pas à la résolution de surcharge.

La norme C++ indique que si la stratégie est launch::async, la fonction se comporte comme si elle appelait l’objet pouvant être appelé dans un nouveau thread. Cela signifie que, bien qu’elle entraîne généralement la création d’un thread, l’implémentation peut utiliser d’autres mécanismes pour obtenir un comportement équivalent. Toutefois, l’implémentation de Microsoft n’est actuellement pas conforme strictement à ce comportement. Il obtient des threads à partir de Windows ThreadPool, qui peuvent fournir un thread recyclé plutôt qu’un nouveau thread. Cela signifie que la launch::async stratégie est effectivement implémentée en tant que launch::async|launch::deferred. Une autre implication de l’implémentation basée sur ThreadPool est qu’il n’existe aucune garantie que les variables locales de thread sont détruites une fois le thread terminé. Si le thread est recyclé et fourni à un nouvel appel, asyncles anciennes variables existent toujours. Nous vous recommandons d’éviter d’utiliser des variables locales de thread avec async.

Si policy est launch::deferred, la fonction marque son état asynchrone associé comme contenant une fonction différée et retourne une valeur. Le premier appel à n’importe quelle fonction non retardée qui attend que l’état asynchrone associé soit prêt en vigueur appelle la fonction différée en évaluant INVOKE(dfn, dargs..., Ty).

Dans tous les cas, l’état asynchrone associé de l’objet future n’est pas défini sur prêt tant que l’évaluation n’est INVOKE(dfn, dargs..., Ty) pas terminée, soit en lève une exception, soit en retournant normalement. Le résultat de l’état asynchrone associé est une exception si une exception a été levée, ou la valeur retournée par l’évaluation.

Remarque

Pour un future(ou le dernier shared_future) attaché à une tâche démarrée std::async, le destructeur bloque si la tâche n’est pas terminée ; autrement dit, elle bloque si ce thread n’a pas encore appelé .get() ou .wait() si la tâche est toujours en cours d’exécution. Si un future obtenu à partir de std::async est déplacé en dehors de la portée locale, un autre code qui l’utilise doit être conscient que son destructeur peut empêcher l’état partagé d’être prêt.

La pseudo-fonction INVOKE est définie dans <functional>.

Section spécifique à Microsoft

Lorsque la fonction passée est exécutée de manière asynchrone, elle s’exécute sur le pool de threads Windows. Pour plus d’informations, consultez Pools de threads. Le nombre de threads simultanés est limité à la valeur par défaut du pool de threads, qui est de 500 threads.

Avant Windows 11 et Windows Server 2022, les applications étaient limitées par défaut à un seul groupe de processeurs ayant au maximum 64 processeurs logiques. Cela a limité le nombre de threads en cours d’exécution simultanée à 64. Pour plus d’informations, consultez Groupes de processeurs.

À compter de Windows 11 et Windows Server 2022, les processus et leurs threads ont des affinités de processeur qui s’étendent par défaut sur tous les processeurs du système et sur plusieurs groupes sur plusieurs ordinateurs avec plus de 64 processeurs. La limite du nombre de threads simultanés est désormais le nombre total de processeurs logiques dans le système.

future_category

Retourne une référence à l’objet error_category qui caractérise les erreurs associées aux objets future.

const error_category& future_category() noexcept;

make_error_code

Crée un error_code avec l’objet error_category qui caractérise les erreurs de future.

inline error_code make_error_code(future_errc Errno) noexcept;

Paramètres

Errno
Valeur future_errc qui identifie l’erreur signalée.

Valeur de retour

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

make_error_condition

Crée un error_condition ensemble avec l’objet error_category qui caractérise les future erreurs.

inline error_condition make_error_condition(future_errc Errno) noexcept;

Paramètres

Errno
Valeur future_errc qui identifie l’erreur signalée.

Valeur de retour

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

swap

Échange l’état asynchrone associé d’un objet promise avec celui d’un autre.

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;

Paramètres

Left
Objet gauche promise.

Right
Objet droit promise.

Voir aussi

<future>