ValueTask<TResult> Structure

Définition

generic <typename TResult>
public value class ValueTask : IEquatable<System::Threading::Tasks::ValueTask<TResult>>

public readonly struct ValueTask<TResult> : IEquatable<System.Threading.Tasks.ValueTask<TResult>>

type ValueTask<'Result> = struct

Public Structure ValueTask(Of TResult)
Implements IEquatable(Of ValueTask(Of TResult))

Paramètres de type

Héritage

Object

ValueType

ValueTask<TResult>

Implémente

IEquatable<ValueTask<TResult>>

Remarques

Une ValueTask<TResult> instance peut être attendue ou convertie en Task<TResult> utilisation AsTask. Une ValueTask<TResult> instance ne peut être attendue qu’une seule fois, et les consommateurs ne peuvent pas lire Result tant que l’instance n’est pas terminée. Si ces limitations sont inacceptables, convertissez-les ValueTask<TResult> en un Task<TResult> en appelant AsTask.

Les opérations suivantes ne doivent jamais être effectuées sur une ValueTask<TResult> instance :

• En attente de l’instance plusieurs fois.
• Appel AsTask plusieurs fois.
• Utilisation .Result ou .GetAwaiter().GetResult() lorsque l’opération n’a pas encore été terminée, ou quand elle les utilise plusieurs fois.
• Utilisation de plusieurs de ces techniques pour consommer l’instance.

Si vous effectuez l’une des versions ci-dessus, les résultats ne sont pas définis.

Une méthode peut retourner une instance de ce type de valeur lorsqu’il est probable que le résultat de son opération sera disponible de manière synchrone, et quand elle est censée être appelée si fréquemment que le coût d’allocation d’un nouvel Task<TResult> appel sera prohibitif.

Il y a des compromis à l’utilisation d’un ValueTask<TResult> au lieu d’un Task<TResult>. Par exemple, alors qu’un ValueTask<TResult> peut aider à éviter une allocation dans le cas où le résultat réussi est disponible de manière synchrone, il contient également plusieurs champs, tandis qu’un Task<TResult> type de référence est un seul champ. Cela signifie que le retour d’une ValueTask<TResult> méthode entraîne la copie de données supplémentaires. Cela signifie également que si une méthode qui retourne une ValueTask<TResult> valeur est attendue dans une méthode asynchrone, l’ordinateur d’état de cette méthode asynchrone sera plus volumineux, car il doit stocker un struct contenant plusieurs champs au lieu d’une référence unique.

Pour les utilisations autres que la consommation du résultat d’une opération asynchrone à l’aide d’await, ValueTask<TResult> peut entraîner un modèle de programmation plus complexe qui nécessite plus d’allocations. Par exemple, considérez une méthode qui peut retourner une Task<TResult> tâche mise en cache comme résultat commun ou un ValueTask<TResult>. Si le consommateur du résultat souhaite l’utiliser en tant que Task<TResult> méthode semblable WhenAll ou WhenAny, il ValueTask<TResult> doit d’abord être converti en Task<TResult> un usage AsTask, ce qui entraînerait une allocation qui aurait été évitée si un cache Task<TResult> avait été utilisé en premier lieu.

Par conséquent, le choix par défaut pour toute méthode asynchrone doit être de retourner un Task ou Task<TResult>. Seulement si l’analyse des performances prouve qu’il vaut la peine d’être ValueTask<TResult> utilisée au lieu d’un Task<TResult>. La version non générique de ValueTask n’est pas recommandée pour la plupart des scénarios. La CompletedTask propriété doit être utilisée pour remettre un singleton terminé correctement dans le cas où une méthode retournant une Task opération se termine de façon synchrone et réussie.