Asynchrone vs multithreading - Y a-t-il une différence?

StackOverflow https://stackoverflow.com/questions/600795

Question

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?

Wikipedia dit :

  

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 selon 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 simples? Comment est-ce possible?

Était-ce utile?

La solution

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, avec un pool de threads ou un processus externe préexistant. 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 n'attend pas la réponse et que l'activité asynchrone ne se produit pas dans le thread appelant.

Au-delà de cela, vous devrez être plus précis.

Autres conseils

Chaque fois que l'opération devant être exécutée de manière asynchrone ne nécessite pas le travail de la CPU, cette opération peut être effectuée sans générer de nouveau thread. Par exemple, si l'opération asynchrone est E / S, la CPU n'a pas à attendre que l'opération d'E / S soit terminée. Il suffit de démarrer l'opération et de passer ensuite à un autre travail 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 informe le processeur de l’interruption de son exécution et le système d’exploitation transmet ensuite l’événement à votre application.

Les abstractions et les API de niveau supérieur fréquents 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é engendre juste une opération d'E / S.

Si l'opération asynchrone nécessite le bon fonctionnement de la CPU, cette opération doit généralement être exécutée dans un autre thread afin d'être réellement asynchrone. Même dans ce cas, il ne sera réellement asynchrone que s’il existe plusieurs unités d’exécution.

Non, les appels asynchrones n'impliquent pas toujours des threads.

Ils lancent 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.

Multi threading fait référence à plusieurs opérations se déroulant dans le même processus. La programmation asynchrone s'étend sur tous les processus. Par exemple, si mes opérations appellent un service Web, le thread ne doit pas attendre le retour du service Web. Ici, nous utilisons la programmation asynchrone qui permet au thread d’attendre la fin d’un processus dans une autre machine. Et lorsqu'il commence à recevoir une réponse du service Web, il peut interrompre le fil principal pour indiquer que le service Web a terminé le traitement de la demande. Le thread principal peut maintenant traiter le résultat.

JavaScript est mono-threadé et asynchrone. Lorsque vous utilisez XmlHttpRequest, par exemple, vous lui fournissez une fonction de rappel qui sera exécutée de manière asynchrone au retour de la réponse.

John Resig a une bonne explication de la question connexe du fonctionnement des chronomètres 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 prendre en charge les 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 invoquant l'appel. Donc, si la question est, un appel asynchrone nécessite-t-il un thread dans le processus actuel, la réponse est non. Cependant, il doit exister un thread d’exécution quelque part pour traiter la demande asynchrone.

Fil d'exécution est un terme vague. Dans les systèmes de tâches coopératifs tels que les anciens systèmes Macintosh et Windows, le fil d'exécution pourrait simplement être le même processus qui a conduit la demande à exécuter une autre pile, un pointeur d'instruction, etc. Cependant, lorsque les gens parlent généralement d'appels asynchrones , ils désignent généralement les appels traités par un autre thread s’il s’agit d’un processus intra-processus (c’est-à-dire au sein du même processus) ou par un autre processus s’il s’agit d’un processus inter-processus.

Notez que la communication inter-processus (ou interprocess) (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 traité par les threads exécution run in.

Certains systèmes vous permettent de tirer parti de la simultanéité dans le noyau pour certaines installations utilisant des rappels. Pour une instance plutôt obscure, des rappels d'E / S asynchrones ont été utilisés pour implémenter des serveurs Internet non bloquants à l'époque multitâche sans préemption de Mac System 6-8.

Ainsi, vous avez des flux d’exécution simultanés " dans " vous programmez sans thread en tant que tel .

Asynchrone signifie simplement que vous ne bloquez pas votre programme en attendant quelque chose (appel de fonction, périphérique, etc.). 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 un système de contrôle d’événement afin d’obtenir un comportement de type asynchrone.

Il existe des exemples de programmes asynchrones mono-threadés. 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 à s'exécuter pendant l'appel, vous devez soit créer un nouveau thread, ou au moins . utilisez un autre thread que vous avez créé uniquement à des fins de gestion des rappels asynchrones.

Parfois, en fonction de la situation, vous souhaiterez peut-être appeler une méthode asynchrone mais lui donner l'impression que l'utilisateur est synchrone (c'est-à-dire bloquer jusqu'à ce que la méthode asynchrone indique 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 son lancement, sans forcer l'appelant à attendre qu'elle se termine avant d'exécuter un autre code.

Au lieu de bloquer le programme appelant (ou le thread) jusqu'à l'arrivée d'une réponse, une implémentation asynchrone (également appelée non-bloquante) enverra une requête à la base de données ou au service Web, ou autre, puis reviendra immédiatement, laissant ainsi votre programme continuer. exécuter un autre code pendant que le service distant envoie une réponse. Une fois la réponse reçue, le système exécutera un rappel (soit sur votre boucle de message, soit dans un thread de port d'achèvement IO distinct, en fonction de l'environnement), laissant votre code gérer la réponse.

Le

Multi-threading signifie que vous exécutez plusieurs threads d'exécution à la fois. Dans ce modèle, toutes les opérations sont toujours synchrones, mais la CPU exécute plusieurs threads d'opérations synchrones en même temps.

Le multi-threading est tout à fait judicieux lorsque vous appelez plusieurs opérations (et indépendantes) liées à la CPU, sur un processeur multicœur. Par exemple, un programme analysant indépendamment chaque pixel d’une image pourrait diviser l’image en une bande pour chaque cœur de CPU, puis analyser chaque bande simultanément dans son propre fil.

Lisez-en plus ici - https: // blog. slaks.net/2014-12-23/parallelism-async-threading-explained/

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top