Asynchrone vs Multithreading - Est-il une différence?

chaque fois que l'opération qui doit se produire de façon asynchrone ne nécessite pas le travail de L'UNITÉ CENTRALE, cette opération peut être effectuée sans frayer un autre fil. Par exemple, si l'opération async est en E/S, le CPU n'a pas à attendre que l'e/s soit terminée. Il 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.) le I/O de travail. Le matériel permet au CPU de savoir quand il est terminé en interrompant le PROCESSEUR et l'OS délivre alors l'événement à votre application.

souvent, les abstractions de haut niveau et les API n'exposent pas les API asynchrones sous-jacentes disponibles à partir de L'OS 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é n'attend qu'une opération d'e/s.

si le fonctionnement asynchrone exige que le CPU fasse un travail, alors généralement ce fonctionnement doit se produire dans un autre fil pour qu'il soit vraiment asynchrone. Même alors, il ne sera véritablement asynchrone si il n'y a plus d'une unité d'exécution.

non, les appels asynchrones n'impliquent pas toujours des fils.

Ils font généralement début d'une 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 d'autres périphériques (comme un contrôleur de disque), par un autre ordinateur sur le réseau, ou par un être humain. Les fils ne sont pas le seul moyen de faire les choses en parallèle.

Multi-threading se réfère à plus d'une opération qui se produit dans le même processus. Tandis 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 async qui permet au thread de ne pas attendre qu'un processus dans une autre machine soit terminé. Et quand il commence à recevoir la réponse du webservice il peut interrompre le fil principal pour dire que le service web a terminé le traitement demande. Maintenant le fil 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 de la question connexe de la façon dont temporisateurs fonctionnent en JavaScript .

Windows a toujours eu un traitement asynchrone depuis les temps non préventifs (versions 2.13, 3.0, 3.1, etc) en utilisant la boucle de message, bien avant de supporter des threads réels. Donc, pour répondre à votre question, non, il n'est pas nécessaire de créer un thread pour effectuer le 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, est un appel asynchrone besoin d'un thread dans le processus actuel, la réponse est non. Cependant, il doit y avoir un fil d'exécution quelque part qui traite la requête asynchrone.

fil D'exécution est un terme vague. Dans un système coopératif de tâches comme les premiers Macintosh et Windows OS'es, le fil de l'exécution pourrait simplement être le même processus qui a fait la requête en exécutant 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 qui sont traités par un autre fil s'il s'agit d'un processus intra-processus (c.-à-d. dans le même processus) ou par un autre processus s'il s'agit d'un processus inter-processus.

noter que la communication inter-processus (ou interprocess) (IPC) est généralement généralisée pour inclure la communication intra-processus, puisque la les techniques de verrouillage et de synchronisation des données sont généralement les mêmes, quel que soit le processus dans lequel les différents threads d'exécution s'exécutent.

certains systèmes vous permettent de profiter de la concurrence dans le noyau pour certaines installations utilisant des callbacks. Dans un cas plutôt obscur, des appels IO asynchrones ont été utilisés pour mettre en œuvre des coupures internet non bloquantes de retour dans les jours sans préemption multitâche du système Mac 6-8.

de cette façon vous avez des flux d'exécution concurrents" dans "vous programmez sans threads comme tel .

asynchrone signifie simplement que vous ne bloquez pas votre programme en attente de quelque chose (appel de fonction, périphérique, etc.) finir. 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 de parvenir ainsi à un comportement asynchrone.

il existe des exemples de programmes asynchrones à filetage simple. 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 voulez que l'application continue à tourner pendant que l'appel est en cours, vous aurez soit besoin de spawn un nouveau thread, ou au moins utilisez un autre thread que vous avez créé uniquement dans le but de gérer les callbacks asynchrones.

Parfois, selon la situation, vous pouvez invoquer une méthode asynchrone, mais de faire apparaître à la l'utilisateur doit être synchrone (c.-à-d. bloquer jusqu'à ce que la méthode asynchrone indique qu'elle est complète). Cela peut être réalisé grâce à Win32 APIs tels que WaitForSingleObject .

An opération asynchrone est une opération qui se poursuit en arrière-plan après avoir été initialisée, sans forcer l'appelant à attendre qu'il termine avant de lancer un autre code.

au lieu de bloquer le programme appelant (ou le thread) jusqu'à ce qu'une réponse arrive, une implémentation asynchrone (aussi appelée non-blocage) enverra une demande à la base de données ou au service web ou quoi que ce soit, puis reviendra immédiatement, laissant votre programme continuer à utiliser un autre code pendant que le service à distance envoie une réponse. Une fois la réponse arrivée, le système lancera un callback (soit sur votre boucle de message, soit dans un port d'achèvement IO séparé, selon l'environnement), laissant votre code gérer la réponse.

multi-threading signifie exécuter plus d'un thread d'exécution à la fois. Dans ce modèle, toutes les opérations sont toujours synchrones, mais le CPU exécutera plusieurs threads de opérations synchrones en même temps.

multi-threading fait le plus de sens quand on appelle des opérations multiples (et indépendantes) liées au CPU, sur un processeur multi-core. Par exemple, un programme qui analyse indépendamment chaque pixel dans une image pourrait diviser l'image en une bande pour chaque noyau CPU, puis analyser chaque bande dans son propre thread en même temps.

lire la suite ici - https://blog.slaks.net/2014-12-23/parallelism-async-threading-explained /