Asynchrone vs multithreading - Y a-t-il une différence?
Un appel asynchrone crée-t-il toujours un nouveau thread? Quelle est la différence entre les deux?
Un appel asynchrone crée-t-il ou utilise-t-il toujours un nouveau thread?
En programmation informatique, les événements asynchrones sont ceux qui se produisent indépendamment du flux de programme principal. Les actions asynchrones sont des actions exécutées dans un schéma non bloquant, permettant au flux principal du programme de poursuivre le traitement.
Je sais que les appels asynchrones peuvent être effectués sur des threads uniques? Comment est-ce possible?
Cette question est sacrément trop générale pour y répondre.
Dans le cas général, un appel asynchrone ne crée pas nécessairement un nouveau thread. C'est une façon de l'implémenter, un pool de threads préexistant ou un processus externe étant d'autres moyens. Cela dépend fortement du langage, du modèle d'objet (le cas échéant) et de l'environnement d'exécution.
Asynchrone signifie simplement que le thread appelant ne s'assoit pas et n'attend pas la réponse, ni l'activité asynchrone ne se produit dans le thread appelant.
Au-delà de cela, vous devrez être plus précis.
Chaque fois que l'opération qui doit se produire de manière asynchrone ne nécessite pas que le CPU fonctionne, cette opération peut être effectuée sans générer un autre thread. Par exemple, si l'opération asynchrone est des E/S, la CPU n'a pas à attendre la fin des E/S. Il lui suffit de démarrer l'opération et peut ensuite passer à d'autres travaux pendant que le matériel d'E/S (contrôleur de disque, interface réseau, etc.) effectue le travail d'E/S. Le matériel permet au CPU de savoir quand il a fini en interrompant le CPU, et le système d'exploitation fournit ensuite l'événement à votre application.
Les abstractions et les API de niveau supérieur n'exposent pas les API asynchrones sous-jacentes disponibles à partir du système d'exploitation et du matériel sous-jacent. Dans ces cas, il est généralement plus facile de créer des threads pour effectuer des opérations asynchrones, même si le thread généré attend simplement une opération d'E/S.
Si l'opération asynchrone nécessite que le CPU fonctionne, alors généralement cette opération doit se produire dans un autre thread pour qu'elle soit vraiment asynchrone. Même alors, il ne sera vraiment asynchrone que s'il y a plus d'une unité d'exécution.
Non, les appels asynchrones n'impliquent pas toujours des threads.
Ils démarrent généralement une sorte d'opération qui se poursuit en parallèle avec l'appelant. Mais cette opération peut être gérée par un autre processus, par le système d'exploitation, par un autre matériel (comme un contrôleur de disque), par un autre ordinateur du réseau ou par un être humain. Les threads ne sont pas le seul moyen de faire avancer les choses en parallèle.
Le filetage multiple fait référence à plusieurs opérations se déroulant dans le même processus. Alors que la programmation asynchrone se propage à travers les processus. Par exemple, si mes opérations appellent un service Web, le thread n'a pas besoin d'attendre le retour du service Web. Ici, nous utilisons la programmation asynchrone qui permet au thread de ne pas attendre la fin d'un processus sur une autre machine. Et lorsqu'il commence à recevoir une réponse du service Web, il peut interrompre le thread principal pour indiquer que le service Web a terminé le traitement de la demande. Maintenant, le thread principal peut traiter le résultat.
JavaScript est monothread et asynchrone. Lorsque vous utilisez XmlHttpRequest, par exemple, vous lui fournissez une fonction de rappel qui sera exécutée de manière asynchrone lorsque la réponse reviendra.
John Resig a une bonne explication du problème connexe de la façon dont les minuteurs fonctionnent en JavaScript .
Windows a toujours eu un traitement asynchrone depuis les temps non préemptifs (versions 2.13, 3.0, 3.1, etc.) en utilisant la boucle de message, bien avant de supporter de vrais threads. Donc, pour répondre à votre question, non, il n'est pas nécessaire de créer un thread pour effectuer un traitement asynchrone.
Les appels asynchrones n'ont même pas besoin de se produire sur le même système/périphérique que celui qui appelle l'appel. Donc, si la question est, un appel asynchrone nécessite-t-il un thread dans le processus en cours, la réponse est non. Cependant, il doit y avoir un thread d'exécution quelque part traitant la demande asynchrone.
Le fil d'exécution est un terme vague. Dans les systèmes de tâches coopératifs tels que les premiers Macintosh et Windows OS, le thread d'exécution pourrait simplement être le même processus qui a fait que la requête exécutait une autre pile, un pointeur d'instruction, etc ... Cependant, lorsque les gens parlent généralement d'appels asynchrones , ils signifient généralement des appels qui sont traités par un autre thread s'il est intra-processus (c'est-à-dire au sein du même processus) ou par un autre processus s'il est inter-processus.
Notez que la communication inter-processus (ou interprocessus) (IPC) est généralement généralisée pour inclure la communication intra-processus, car les techniques de verrouillage et de synchronisation des données sont généralement les mêmes quel que soit le processus d'exécution des threads séparés d'exécution. po.
Certains systèmes vous permettent de profiter de la simultanéité dans le noyau pour certaines fonctionnalités utilisant des rappels. Pour une instance assez obscure, des rappels asynchrones IO ont été utilisés pour implémenter des serveurs Internet non bloquants à l'époque multitâche sans préemption du Mac System 6-8.
De cette façon, vous avez des flux d'exécution simultanés "dans" votre programme sans thread en tant que tel.
Asynchrone signifie simplement que vous ne bloquez pas votre programme en attendant que quelque chose (appel de fonction, périphérique, etc.) se termine. Il peut être implémenté dans un thread séparé, mais il est également courant d'utiliser un thread dédié pour les tâches synchrones et de communiquer via une sorte de système d'événements et ainsi obtenir un comportement de type asynchrone.
Il existe des exemples de programmes asynchrones à thread unique. Quelque chose comme:
...do something
...send some async request
while (not done)
...do something else
...do async check for results
La nature des appels asynchrones est telle que, si vous souhaitez que l'application continue de fonctionner pendant que l'appel est en cours, vous devrez soit générer un nouveau thread, ou au moins utilisez un autre thread que vous avez créé uniquement dans le but de gérer les rappels asynchrones.
Parfois, selon la situation, vous souhaiterez peut-être invoquer une méthode asynchrone mais la faire apparaître comme synchrone pour l'utilisateur (c'est-à-dire bloquer jusqu'à ce que la méthode asynchrone ait signalé qu'elle est terminée). Cela peut être réalisé via des API Win32 telles que WaitForSingleObject .
Une opération asynchrone est une opération qui se poursuit en arrière-plan après avoir été lancée, sans forcer l'appelant à attendre qu'il se termine avant d'exécuter un autre code.
Au lieu de bloquer le programme appelant (ou le thread) jusqu'à ce qu'une réponse arrive, une implémentation asynchrone (également appelée non bloquante) enverra une demande à la base de données ou au service Web ou autre, puis reviendra immédiatement, laissant votre programme continuer à exécuter un autre code tandis que le service distant envoie une réponse. Une fois la réponse arrivée, le système exécutera un rappel (soit sur votre boucle de message, soit dans un thread de port de complétion IO, en fonction de l'environnement), laissant votre code gérer la réponse.
Le multi-threading signifie l'exécution de plus d'un thread d'exécution à la fois. Dans ce modèle, toutes les opérations sont toujours synchrones, mais le processeur exécutera plusieurs threads d'opérations synchrones en même temps.
Le multithread est plus judicieux lors de l'appel de plusieurs opérations liées au processeur (et indépendantes), sur un processeur multicœur. Par exemple, un programme qui analyse indépendamment chaque pixel d'une image pourrait diviser l'image en une bande pour chaque cœur de processeur, puis analyser chaque bande dans son propre thread en même temps.
En savoir plus ici