La programmation asynchrone implique-t-elle le multithreading ?

Question

Parlons du code JavaScript qui a setInterval méthodes toutes 2 sec.

J'ai aussi un onblur événement d'animation pour un certain contrôle.

Dans un cas où onblur se produit (+ animation), je pourrais obtenir la setInterval fonction.

Pregunta :
La programmation asynchrone implique-t-elle le multithreading (de quelque manière que ce soit) ?

Answer 1

Non. Ça veut dire littéralement ce que ça veut dire : asynchrone. Comprendre la différence entre la programmation asynchrone et la programmation basée sur les threads est essentiel pour votre réussite en tant que programmeur.

Dans un environnement traditionnel, non threadé, lorsqu'une fonction doit attendre un événement externe (tel qu'un événement réseau, un événement clavier ou souris, ou même un événement horloge), le programme doit attendre jusqu'à ce que cet événement se produise.

Dans un environnement multithread, de nombreux fils de programmation individuels sont exécutés en même temps. (Selon le nombre de processeurs et le support du système d'exploitation, cela peut être littéralement vrai, ou bien il peut s'agir d'une illusion créée par des algorithmes d'ordonnancement sophistiqués). Pour cette raison, les environnements multithreads sont difficiles et impliquent des problèmes de verrouillage de la mémoire des threads pour les empêcher de se dépasser.

Dans un environnement asychrone, un seul fil de processus fonctionne en permanence, mais il peut, pour des raisons événementielles (et c'est là l'essentiel), passer d'une fonction à une autre. Quand un événement se produit, et lorsque le processus en cours d'exécution atteint un point où il doit attendre un autre événement le noyau javascript parcourt alors sa liste d'événements et transmet le suivant, dans un ordre (formellement) indéterminé (mais probablement déterministe), au gestionnaire d'événements.

C'est la raison pour laquelle la programmation asynchrone et événementielle évite de nombreux pièges de la programmation multithread traditionnelle, tels que les problèmes de contention de la mémoire. Il peut toujours y avoir des conditions de course, car l'ordre dans lequel les événements sont traités ne dépend pas de vous, mais elles sont rares et plus faciles à gérer. D'autre part, comme le gestionnaire d'événements ne fournit pas d'événements avant que la fonction en cours d'exécution n'atteigne un point mort, certaines fonctions peuvent affamer le reste de la programmation. C'est ce qui se passe dans Node.js, par exemple, lorsque les gens font bêtement beaucoup de mathématiques lourdes dans le serveur - il vaut mieux les mettre dans un petit serveur que Node "attend" pour fournir la réponse. Node.js est un excellent petit standard téléphonique pour les événements, mais tout ce qui prend plus de 100 millisecondes devrait être géré de manière client/serveur.

Dans l'environnement du navigateur, les événements DOM sont traités comme des points d'événements automatiques (ils doivent l'être, la modification du DOM fournit beaucoup d'événements), mais même là, un Javascript mal écrit peut affamer le noyau, c'est pourquoi Firefox et Chrome ont tous deux ces gestionnaires d'interruption "Ce script a cessé de répondre".

Answer 2

Une boucle d'événement à fil unique est un bon exemple d'asynchronisme dans un langage à fil unique.

Le concept ici est que vous attachez doLater aux gestionnaires de rappel de l eventLoop . Ensuite, le eventLoop est juste un while(true) qui vérifie si le timestamp spécifique pour chaque doLater est satisfaite, et si c'est le cas, il appelle le gestionnaire.

Pour ceux qui sont intéressés, voici une implémentation naïve (et horriblement inefficace en tant que jouet) d'une boucle d'événement à fil unique en JavaScript

Cela signifie que, sans aucun accès au planificateur de threads du système d'exploitation pour votre thread unique, vous êtes contraint d'attendre activement le doLater les rappels.

Si vous avez un sleep vous pourriez simplement faire sleep jusqu'au prochain doLater qui est plus efficace qu'une attente occupée, puisque vous désordonnez votre unique thread et laissez le système d'exploitation faire autre chose.

Answer 3

1. Non, la programmation asynchrone ne signifie pas spécifiquement le multithreading.

2. Pour réaliser plusieurs tâches en même temps, nous utilisons le multithreading et l'architecture de boucle d'événement dans node js.

3. JavaScript est synchrone et monofilaire et c'est pourquoi node js est également monofilaire mais avec la boucle d'événement, node effectue des opérations d'E/S non bloquantes. Node.js utilise la bibliothèque libuv qui utilise un pool de threads de taille fixe qui gère l'exécution de tâches parallèles.

Le fil est une séquence d'instructions de code et aussi la sous-unité du processus.

En multithreading, les processus ont plusieurs threads. Dans le cas du single threading, les processus ont un seul thread.

Answer 4

Seulement dans le sens où il exécute le code de façon désordonnée et risque des conditions de course. Vous n'obtiendrez aucun avantage en termes de performances en utilisant les délais d'attente et les intervalles.

Cependant, les WebWorkers de HTML5 permettent un véritable multithreading dans le navigateur : http://www.html5rocks.com/en/tutorials/workers/basics/

Answer 5

S'il y a un rappel, quelque chose doit l'appeler. Les unités d'exécution sont les threads & donc, oui, un autre thread doit appeler le callback, soit directement, soit en mettant en file d'attente un appel de procédure asynchrone au thread initiateur.