Brève explication de la Async/Await dans .Net 4.5

Question

Comment tâches Asynchrones (Async/Await) de travail .Net 4.5?

Un exemple de code:

private async Task<bool> TestFunction()
{
  var x = await DoesSomethingExists();
  var y = await DoesSomethingElseExists();
  return y;
}

Le deuxième await instruction est exécutée immédiatement ou après la première await retours?

Answer 1

await pause de la méthode jusqu'à ce que l'opération est terminée. Ainsi, la deuxième await était exécutée après la première await de rendement.

Pour plus d'informations, voir mon async / await intro ou la FAQ officielle.

Answer 2

Il s'exécute après les premiers attendent les retours. Si cette chose vous trouble, essayez de jouer avec des points d'arrêt - ils sont entièrement pris en charge par le nouveau modèle asynchrone.

Imaginez, il devrait ressembler à ceci:

var x = await GetSomeObjectInstance();
var y = await GetSomeObjectInstance2(x);

Il serait probablement se produire une NullReferenceException quelque part, donc, la première attendent a de retour en premier. Sinon, x serait nulle/non défini ou que ce soit.

Answer 3

Les appels de méthodes va encore se produire de manière séquentielle comme "régulier" non attendue des appels de méthode. Le but de l'attendent, c'est que reviendra le thread actuel du pool de threads, alors que l'attendu de l'opération s'enfuit et n'importe quoi.

Ceci est particulièrement utile dans les environnements hautes performances à dire un serveur web où la demande est traitée sur un thread particulier de l'ensemble du pool de threads. Si nous ne nous attendons alors le thread de traitement de la demande (et toutes ses ressources) reste "en cours d'utilisation", tandis que le db / appel de service terminée (cela peut prendre quelques secondes en particulier pour les appels de service externes).

Maintenant, dans un faible volume de trafic des sites web ce n'est pas vraiment un problème, mais dans des sites très fréquentés le coût de tous ces threads de demande simplement assis autour d'une "utilisation" de l'état en attente pour d'autres processus, comme db /appels de service à remplir peut être une charge.

Nous sommes mieux de libérer le fil de retour pour le pool de travail pour lui permettre de faire d'autres tâches utiles pour une autre requête.

Puis, quand la bd d'appel / appel de service complète, nous interrompre le fil de la piscine et de demander un thread à exécuter sur le traitement de la demande à partir de là où nous l'avions laissé. À ce point l'état de la demande est rechargée et l'appel de la méthode continue.

Donc par demander les choses vont toujours prendre la même quantité de temps. Mais dans l'ensemble, à travers toutes les demandes choses peuvent sembler plus performant pour les utilisateurs que le serveur web (dans ce cas) est plus efficace avec une meilleure utilisation des ressources.

Il y a un frais de changement à ce bien malgré ce que vous voyez dans les modèles par défaut et dans de nombreux documents, vous ne devriez pas simplement aveuglément utilisation attendent pour chaque appel. C'est juste un outil, et comme tous les outils il a sa place. Si le coût de migration n'est pas moins que le coût de vient de terminer vos appels en mode synchrone, alors vous ne devriez pas utiliser les attendent.