Est-il exact de dire que JavaScript est un langage "single-thread" ?

Question

J'ai entendu ce genre de déclarations à plusieurs reprises, mais personnellement je pense que cela n'a pas tout à fait de sens. Je pense que les gens confondent JavaScript en tant que spécification de langage et JavaScript en pratique (navigateur, Node, etc.). Bien sûr, dans la plupart des cas, JavaScript est exécuté dans un environnement à un seul thread, mais, à ma connaissance, rien dans les spécifications du langage ne l'exige. Je pense que c'est comme dire que Python est "interprété", alors que c'est en fait entièrement une question d'implémentation.

Alors, est-il exact de dire que JavaScript est un langage "single-thread" ?

Answer 1

Par JavaScript, vous semblez vouloir dire ECMAScript.

Il y a déjà du multithreading dans le navigateur, construit avec webworkers et repose sur une forte isolation des données : les travailleurs ne communiquent que par messages, rien n'est partagé.

Si vous souhaitez un multithreading plus complexe, avec partage des données, cela ne semble pas possible pour le moment. Rien dans ECMAScript n'interdit explicitement le multithreading, mais vous ne pouvez pas faire du multithreading sans

• la possibilité de créer des "threads" (au sens général, il pourrait s'agir de coroutines)
• les mutex et les moyens de synchroniser les accès
• un support de bas niveau pour garantir, par exemple, qu'un changement de propriété ne casse pas les données en cas d'accès simultanés. Aucun des moteurs actuels n'a été conçu avec ce genre de force (oui, certains d'entre eux supportent plusieurs threads mais de manière isolée).

Le fait que l'ECMAScript n'ait pas été conçu pour inclure le multithreading est suffisant pour empêcher, à l'heure actuelle, de le prendre en charge (à l'exception du multithreading isolé par le passage de messages, comme cela se fait déjà, mais c'est un type de multithreading très limité).

Vous devez réaliser que

• le partage des données en multithreading est très coûteux (sans même parler des actions simultanées sur le DOM)
• vous l'utiliserez rarement en JavaScript

Pourquoi ai-je dit que vous l'utiliseriez rarement ? Parce que la plupart des tâches bloquantes d'entrée/sortie (lecture de fichiers, requêtes, requêtes de base de données, etc.), la plupart des tâches de bas niveau (par exemple, le décodage d'images ou le rendu de pages), la plupart de la gestion de l'interface utilisateur (avec la file d'attente des événements), la plupart de la planification (délais et intervalles) sont effectuées à l'extérieur.

Answer 2

Le comportement multithreading est disponible à la fois dans HTML5 et node.js, MAIS il n'y a pas d'API native de threading dans le langage Javascript, donc je suppose que la réponse à votre question inventée (je le dis de la manière la plus gentille possible, bien sûr) est "oui, Javascript est un langage monofilaire".

Answer 3

AFAIK, rien dans la spécification du langage n'exige qu'il en soit ainsi.

Sur TC39 il est dit :

À tout moment, il y a au plus un contexte d'exécution par agent qui exécute effectivement du code.

Cela me semble être la garantie cruciale que vous ne devrez jamais synchroniser l'accès aux variables dans ECMAScript. C'est ce que je pense que l'on veut dire quand quelqu'un dit qu'un fichier langue est monofilière.

Bien sûr, la plupart des environnements hôtes ECMAScript utilisent plus d'un thread dans leur implémentation d'environnement hôte pour des choses comme la collecte des déchets, etc. De plus, ECMAScript lui-même autorise l'utilisation de plusieurs threads. des contextes d'exécution distincts qui peuvent chacun être entraînés par leur propre fil - bien que la norme indique clairement que vous pouvez également les entraîner tous avec le même fil.

L'idée, encore une fois, est qu'il n'est jamais nécessaire de protéger une variable ECMAScript avec un mutex, un sémaphore ou autre (c'est pourquoi l'ECMAScript ne fournit pas de telles facilités) puisque le langage promet qu'il n'y aura jamais deux fils de contrôle avec un accès simultané au même contexte.

Je ne connais pas non plus d'implémentation JavaScript qui viole cette promesse, bien que cela soit possible.