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

Comment les tâches asynchrones (Async / Await) fonctionnent-elles dans .Net 4.5?

Un exemple de code:

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

Est-ce que la deuxième déclaration d’ await est exécutée immédiatement ou après la première await retour?

await pause de la méthode jusqu’à la fin de l’opération. Donc, la deuxième await serait exécutée après la première await retour.

Pour plus d’informations, consultez mon introduction async / waiting ou la FAQ officielle .

Il s’exécute après la première attente des retours. Si cela vous dérange, essayez de jouer avec des points d’arrêt – ils sont entièrement pris en charge par le nouveau modèle asynchrone.

Imaginez que cela ressemble à ceci:

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

Il se produirait probablement une exception NullReferenceException quelque part, donc la première attente doit retourner en premier. Sinon, x serait nul / non défini ou autre.

Les appels de méthodes se produiront toujours de manière séquentielle, tout comme les appels de méthode “non attendus”. Le but de wait est de retourner le thread en cours au pool de threads pendant que l’opération attendue s’exécute et fait quoi que ce soit.

Cela est particulièrement utile dans les environnements hautes performances, par exemple un serveur Web, où une requête donnée est traitée sur un thread donné à partir du pool de threads global. Si nous n’attendons pas, alors le thread en cours de traitement de la requête (et de toutes ses ressources) rest “en cours d’utilisation” à la fin de l’appel db / service. Cela peut prendre quelques secondes ou plus, en particulier pour les appels de service externes.

Désormais, sur les sites Web à faible trafic, cela ne pose pas vraiment de problème, mais dans les sites à fort trafic, le coût de tous ces threads de requêtes ne fait que ralentir, dans un état d’utilisation, en attente d’autres processus. retourner peut être une charge de ressources.

Il est préférable de renvoyer le thread au pool de travail pour lui permettre d’effectuer d’autres tâches utiles pour une autre demande.

Une fois l’appel de firebase database / service terminé, nous pouvons alors interrompre le pool de threads et demander à un thread de continuer à traiter cette requête là où elle l’avait laissée. A ce stade, l’état de la demande est rechargé et l’appel de la méthode continue.

Donc, sur demande, lorsque vous utilisez wait, la demande prendra toujours le même temps du sharepoint vue des utilisateurs … plus un petit plus pour la surcharge.

Mais dans l’ensemble, pour toutes les demandes de tous les utilisateurs, les choses peuvent sembler plus performantes pour tous les utilisateurs, car le serveur Web (dans ce cas) fonctionne plus efficacement avec une meilleure utilisation des ressources. c’est-à-dire qu’il n’a pas à mettre en queue les requêtes en attente de threads gratuits pour traiter les demandes, car nous sums obligés d’acheter plus de matériel parce que nous utilisons la même quantité de matériel débit.

Il y a un coût de changement à cela bien que malgré ce que vous voyez dans les modèles par défaut et dans de nombreux documents, vous ne devriez pas simplement attendre d’attendre aveuglément chaque appel. C’est juste un outil et comme tous les outils, il a sa place. Si le coût de la commutation n’est pas inférieur au coût de la réalisation synchrone de vos appels, vous ne devriez pas attendre.