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?

Wikipedia dit :

En programmation informatique, les événements asynchrones sont ceux qui se produisent indépendamment du flux principal du programme. Les actions asynchrones sont des actions exécutées dans un schéma non bloquant, permettant au flux de programme principal de continuer le traitement.

Je sais que les appels asynchrones peuvent être effectués sur des threads uniques? Comment est-ce possible?

Cette question est presque 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 objet (le cas échéant) et de l'environnement d'exécution.

Asynchrone signifie simplement que le thread appelant ne reste pas assis et n'attend pas la réponse, et l'activité asynchrone ne se produit pas 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 processeur fonctionne, cette opération peut être effectuée sans engendrer un autre thread. Par exemple, si l'opération asynchrone est des E / S, la CPU n'a pas besoin d'attendre la fin des E / S. Il a juste besoin de démarrer l'opération, et peut ensuite passer à 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 CPU quand il a terminé en interrompant le CPU, et le système d'exploitation délivre alors l'événement à votre application.

Souvent, 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 juste une opération d'E / S.

Si l'opération asynchrone nécessite que le processeur fonctionne, alors généralement cette opération doit se produire dans un autre thread pour qu'elle soit vraiment asynchrone. Même dans ce cas, 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 commencent 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 sur le réseau ou par un être humain. Les threads ne sont pas le seul moyen de faire avancer les choses en parallèle.

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 lorsque la réponse est renvoyée.

John Resig a une bonne explication du problème connexe du fonctionnement des minuteries en JavaScript .

Le multi-threading 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 quand 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. Le thread principal peut maintenant traiter le résultat.

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 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, est-ce qu'un appel asynchrone nécessite 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 requête asynchrone.

Le fil d'exécution est un terme vague. Dans un système de tâches coopératif tel que les premiers systèmes d'exploitation Macintosh et Windows, le thread d'exécution pourrait simplement être le même processus que celui qui a fait la demande en exécutant une autre pile, un pointeur d'instructions, etc. Cependant, lorsque les gens parlent généralement d'appels asynchrones , ils signifient généralement des appels traités par un autre thread s'il s'agit d'un intra-processus (c'est-à-dire au sein du même processus) ou par un autre processus s'il s'agit d'un 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 dans lequel s'exécutent les threads d'exécution séparés.

Certains systèmes vous permettent de profiter de la concurrence dans le noyau pour certaines installations utilisant des rappels. Pour un exemple plutôt obscur, des rappels d'E / S asynchrones ont été utilisés pour implémenter des serveurs Internet non bloquants à l'époque du multitâche sans préemption du système Mac 6-8.

De cette façon, vous avez des flux d'exécution simultanés "dans" votre programme sans threads en tant que tels .

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 à un seul thread. 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 frayer un nouveau thread, ou au moins utiliser un autre thread vous que vous avez créé uniquement aux fins de gestion des rappels asynchrones.

Parfois, selon la situation, vous voudrez peut-être invoquer une méthode asynchrone mais la faire apparaître à l'utilisateur comme étant synchrone (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 .