Mise à jour: ASP.NET Core n'a pas deSynchronizationContext
. Si vous êtes sur ASP.NET Core, peu importe que vous l'utilisiez ConfigureAwait(false)
ou non.
Pour ASP.NET "Full" ou "Classic" ou autre, le reste de cette réponse s'applique toujours.
Message d'origine (pour ASP.NET non-Core):
Cette vidéo de l'équipe ASP.NET contient les meilleures informations sur l'utilisation async
sur ASP.NET.
J'avais lu qu'il est plus performant car il n'a pas à basculer les contextes de thread vers le contexte de thread d'origine.
Cela est vrai avec les applications d'interface utilisateur, où il n'y a qu'un seul thread d'interface utilisateur sur lequel vous devez "synchroniser".
Dans ASP.NET, la situation est un peu plus complexe. Lorsqu'une async
méthode reprend l'exécution, elle récupère un thread du pool de threads ASP.NET. Si vous désactivez la capture de contexte à l'aide ConfigureAwait(false)
, le thread continue simplement d'exécuter la méthode directement. Si vous ne désactivez pas la capture de contexte, le thread ré-entrera dans le contexte de la demande et continuera ensuite à exécuter la méthode.
Donc, ConfigureAwait(false)
ne vous enregistre pas un saut de fil dans ASP.NET; cela vous évite de rentrer dans le contexte de la demande, mais cela est normalement très rapide. ConfigureAwait(false)
pourrait être utile si vous essayez de faire une petite quantité de traitement parallèle d'une demande, mais en réalité, TPL est mieux adapté à la plupart de ces scénarios.
Cependant, avec ASP.NET Web Api, si votre demande arrive sur un thread et que vous attendez une fonction et appelez ConfigureAwait (false) qui pourrait potentiellement vous mettre sur un autre thread lorsque vous renvoyez le résultat final de votre fonction ApiController .
En fait, juste faire un await
peut le faire. Une fois que votre async
méthode atteint un await
, la méthode est bloquée mais le thread retourne au pool de threads. Lorsque la méthode est prête à continuer, tout thread est extrait du pool de threads et utilisé pour reprendre la méthode.
La seule différence ConfigureAwait
dans ASP.NET est de savoir si ce thread entre dans le contexte de la demande lors de la reprise de la méthode.
J'ai plus d'informations de fond dans mon article MSDN surSynchronizationContext
et mon async
blog d'introduction .
HttpContext.Current
est acheminé par ASP.NETSynchronizationContext
, qui est acheminé par défaut lorsque vousawait
, mais il n'est pas acheminé parContinueWith
. OTOH, le contexte d'exécution (y compris les restrictions de sécurité) est le contexte mentionné dans CLR via C #, et il est transmis par les deuxContinueWith
etawait
(même si vous utilisezConfigureAwait(false)
).