Async/Await vs Threads

Question

Dans .Net 4.5, Microsoft a ajouté la nouvelle fonction Async/Await pour simplifier le codage asynchrone. Cependant, je me demande

1. Can Async/Await remplacer complètement l'ancienne façon d'utiliser Threads ?
2. Est Async/Await capable de faire tout ce qu'un Thread peut faire de manière asynchrone ?
3. Can Async/Await ne peut être utilisé qu'avec certaines méthodes comme WebClient.DownloadStringAsync ou puis-je convertir n'importe quelle méthode synchrone pour qu'elle utilise Async/Await et ne pas bloquer le fil principal ?

Answer 1

Peut-il remplacer complètement l'ancienne façon d'utiliser les fils ?

Non. Un fil peut faire beaucoup plus de choses utiles. Await est spécifiquement conçu pour traiter quelque chose qui prend du temps, le plus souvent une demande d'entrée/sortie. Ce qui traditionnellement était fait avec un callback lorsque la requête I/O était terminée. L'écriture de code qui s'appuie sur ces callbacks est assez difficile, l'attente le simplifie grandement.

capable de faire tout ce qu'un thread peut faire de manière asynchrone ?

En gros. Await s'occupe simplement de gérer le délai, il ne fait rien d'autre que ce que fait un thread. La fonction await expression ce qui est à droite du mot-clé attendu, est ce qui fait le travail. Idéalement, il n'utilise pas du tout de thread, il envoie une requête au pilote et une fois que le pilote a terminé le transfert de données, il génère un callback de notification d'achèvement. La mise en réseau est de loin l'utilisation la plus courante, les latences de centaines de millisecondes sont courantes et constituent un effet secondaire inévitable des services passant du bureau ou du réseau local au "nuage". L'utilisation de ces services de manière synchrone rendrait l'interface utilisateur peu réactive.

ne peut être utilisé qu'avec certaines méthodes comme WebClient.DownloadStringAsync

Non. Vous pouvez l'utiliser avec n'importe quelle méthode qui renvoie une tâche. Les méthodes XxxxAsync() sont juste des méthodes précuites dans le cadre .NET pour les opérations courantes qui prennent du temps. Comme le téléchargement de données depuis un serveur web.

Answer 2

C'est ainsi que je vois les choses (et je pense que c'est aussi le cas de Microsoft si l'on regarde https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2012/hh191443(v=vs.110)#threads )

Async/await est un moyen rapide d'exécuter du code sur le fil d'exécution principal de l'application, avec l'avantage que le code peut se suspendre lorsqu'il n'a rien à faire et renvoyer le focus au fil d'exécution principal, se "réveiller" sur le fil d'exécution principal lorsqu'il y a un résultat à obtenir, puis renvoyer le traitement au fil d'exécution principal, vous l'aurez deviné. Pensez-y comme une instruction GOTO basée sur des événements dans Basic qui peut transmettre le contrôle à une ligne d'exécution spécifique.

En revanche, un thread est un flux d'exécution distinct qui peut fonctionner avec ses propres variables, etc. et qui, si le matériel est suffisant, est exécuté en parallèle avec le thread principal.

Si vous avez une application GUI qui va télécharger un seul fichier et faire quelque chose avec ce fichier une fois qu'il est téléchargé, je mettrais en œuvre cette méthode en utilisant une méthode async/await.

Cependant, si votre interface graphique doit télécharger 5000 fichiers, je créerais un thread de téléchargement de fichiers pour gérer cela, car le thread principal de l'interface graphique peut se figer pendant que l'exécution est transférée pour gérer le téléchargement des fichiers.

Answer 3

La déclaration officielle à ce sujet. Cependant, vous devriez comprendre les différences entre les threads et la programmation asynchrone avant de remplacer aveuglément une chose par une autre.