Pourquoi avons-nous besoin du mot-clé async?

Je viens de commencer à jouer avec async / wait dans .Net 4.5. Une chose qui m'intéresse au départ, pourquoi le mot-clé async est-il nécessaire? L'explication que j'ai lue était que c'est un marqueur, donc le compilateur sait qu'une méthode attend quelque chose. Mais il semble que le compilateur devrait être capable de comprendre cela sans mot-clé. Que fait-il d'autre?

Il y a plusieurs réponses ici, et toutes parlent de ce que font les méthodes asynchrones, mais aucune ne répond à la question, c'est pourquoi asyncest nécessaire en tant que mot-clé qui va dans la déclaration de fonction.

Ce n'est pas "de demander au compilateur de transformer la fonction d'une manière spéciale"; awaitseul pouvait le faire. Pourquoi? Parce que C # a déjà un autre mécanisme où la présence d'un mot - clé spécial dans le corps de méthode provoque le compilateur pour effectuer extrême (et très similaire à async/await) des transformations sur le corps de la méthode: yield.

Sauf que ce yieldn'est pas son propre mot-clé en C #, et comprendre pourquoi l'expliquera asyncaussi. Contrairement à la plupart des langages qui prennent en charge ce mécanisme, en C #, vous ne pouvez pas dire yield value;à la yield return value;place. Pourquoi? Parce qu'il a été ajouté au langage après que C # existait déjà, et il était tout à fait raisonnable de supposer que quelqu'un, quelque part, aurait pu utiliser yieldle nom d'une variable. Mais parce qu'il n'y avait pas de scénario préexistant dans lequel <variable name> returnétait syntaxiquement correct, a yield returnété ajouté au langage pour permettre d'introduire des générateurs tout en maintenant une compatibilité à 100% avec le code existant.

Et c'est pourquoi a asyncété ajouté comme modificateur de fonction: pour éviter de casser le code existant utilisé awaitcomme nom de variable. Puisqu'aucune asyncméthode n'existait déjà, aucun ancien code n'est invalidé et dans le nouveau code, le compilateur peut utiliser la présence de la asyncbalise pour savoir qui awaitdoit être traité comme un mot-clé et non comme un identifiant.

il change la méthode d'une méthode normale en un objet avec rappel qui nécessite une approche totalement différente pour la génération de code

et quand quelque chose de drastique comme ça arrive, il est habituel de le signifier clairement (nous avons appris cette leçon de C ++)

L'idée avec des mots clés comme "async" ou "unsafe" est de lever toute ambiguïté quant à la façon dont le code qu'ils modifient doit être traité. Dans le cas du mot-clé async, il indique au compilateur de traiter la méthode modifiée comme quelque chose qui n'a pas besoin d'être renvoyé immédiatement. Cela permet au thread où cette méthode est utilisée de continuer sans avoir à attendre les résultats de cette méthode. C'est effectivement une optimisation de code.

OK, voici mon point de vue à ce sujet.

Il y a quelque chose appelé coroutines qui est connu depuis des décennies. ("Knuth and Hopper" -class "pendant des décennies") Ce sont des généralisations de sous - programmes , dans la mesure où non seulement ils obtiennent et relâchent le contrôle au début de la fonction et la déclaration de retour, mais ils le font également à des points spécifiques ( points de suspension ). Un sous-programme est une coroutine sans point de suspension.

Ils sont simples à mettre en œuvre avec des macros C, comme le montre le document suivant sur les "protothreads". ( http://dunkels.com/adam/dunkels06protothreads.pdf ) Lisez-le. J'attendrai...

L'essentiel, c'est que les macros créent un gros switchet une caseétiquette à chaque point de suspension. À chaque point de suspension, la fonction stocke la valeur de l' caseétiquette immédiatement suivante , afin qu'elle sache où reprendre l'exécution la prochaine fois qu'elle sera appelée. Et il rend le contrôle à l'appelant.

Cela se fait sans modifier le flux apparent de contrôle du code décrit dans le "protothread".

Imaginez maintenant que vous avez une grande boucle appelant à tour de rôle toutes ces "protothreads" et que vous obtenez simultanément l'exécution de "protothreads" sur un seul thread.

Cette approche présente deux inconvénients:

1. Vous ne pouvez pas conserver l'état dans les variables locales entre les reprises.
2. Vous ne pouvez pas suspendre le "protothread" à partir d'une profondeur d'appel arbitraire. (tous les points de suspension doivent être au niveau 0)

Il existe des solutions de contournement pour les deux:

1. Toutes les variables locales doivent être remontées au contexte de la protothread (contexte qui est déjà requis par le fait que la protothread doit stocker son prochain point de reprise)
2. Si vous sentez que vous avez vraiment besoin d'appeler une autre protothread à partir d'une protothread, "générez" une enfant protothread et suspendez jusqu'à la fin de l'enfant.

Et si vous aviez le support du compilateur pour faire le travail de réécriture que font les macros et la solution de contournement, vous pouvez simplement écrire votre code de prototread comme vous le souhaitez et insérer des points de suspension avec un mot clé.

Et voici ce asyncet awaitsont tous sur: la création (Stackless) coroutines.

Les coroutines en C # sont réifiées en tant qu'objets de classe (générique ou non générique) Task.

Je trouve ces mots clés très trompeurs. Ma lecture mentale est:

• async comme "suspensible"
• await comme "suspendre jusqu'à la fin de"
• Task comme "futur ..."

Maintenant. Avons-nous vraiment besoin de marquer la fonction async? En plus de dire qu'il devrait déclencher les mécanismes de réécriture de code pour faire de la fonction une coroutine, il résout certaines ambiguïtés. Considérez ce code.

public Task<object> AmIACoroutine() {
    var tcs = new TaskCompletionSource<object>();
    return tcs.Task;
}

En supposant que ce asyncn'est pas obligatoire, est-ce une coroutine ou une fonction normale? Le compilateur devrait-il le réécrire en coroutine ou non? Les deux pourraient être possibles avec une sémantique éventuelle différente.