Fil vert

En programmation informatique , un thread vert est un thread planifié par une bibliothèque d'exécution ou une machine virtuelle (VM) au lieu d'être planifié nativement par le système d'exploitation (OS) sous-jacent. Les threads verts émulent des environnements multithreads sans s'appuyer sur des capacités natives du système d'exploitation, et ils sont gérés dans l'espace utilisateur au lieu de l'espace noyau , ce qui leur permet de fonctionner dans des environnements qui ne prennent pas en charge les threads natifs.

Les threads verts font référence au nom de la bibliothèque de threads d'origine pour le langage de programmation Java (qui a été publiée dans la version 1.1 , puis les threads verts ont été abandonnés dans la version 1.3 au profit des threads natifs). Elle a été conçue par The Green Team chez Sun Microsystems .

Les threads verts ont été brièvement disponibles en Java entre 1997 et 2000.

Les threads verts partagent un seul thread du système d'exploitation via la concurrence coopérative et ne peuvent donc pas obtenir de gains de performances de parallélisme comme les threads du système d'exploitation. Le principal avantage des coroutines et des threads verts est la facilité de mise en œuvre.

Sur un processeur multi-cœur , les implémentations natives de threads peuvent attribuer automatiquement du travail à plusieurs processeurs, alors que les implémentations de threads verts ne le peuvent normalement pas. Les threads verts peuvent être démarrés beaucoup plus rapidement sur certaines machines virtuelles. Sur les ordinateurs monoprocesseurs, cependant, le modèle le plus efficace n'a pas encore été clairement déterminé.

Des tests sur des ordinateurs exécutant le noyau Linux version 2.2 (sorti en 1999) ont montré que :

• Les threads verts surpassent considérablement les threads natifs Linux en termes d'activation et de synchronisation des threads .
• Les threads natifs Linux ont des performances légèrement meilleures sur les opérations d'entrée/sortie (E/S) et de changement de contexte .

Lorsqu'un thread vert exécute un appel système bloquant, non seulement ce thread est bloqué, mais tous les threads du processus sont bloqués. Pour éviter ce problème, les threads verts doivent utiliser des opérations d'E/S non bloquantes ou asynchrones , bien que la complexité accrue du côté utilisateur puisse être réduite si la machine virtuelle implémentant les threads verts génère des processus d'E/S spécifiques (masqués à l'utilisateur) pour chaque opération d'E/S.

Il existe également des mécanismes qui permettent d'utiliser des threads natifs et de réduire la charge liée à l'activation et à la synchronisation des threads :

• Les pools de threads réduisent le coût de création d'un nouveau thread en réutilisant un nombre limité de threads.
• Les langages qui utilisent des machines virtuelles et des threads natifs peuvent utiliser l'analyse d'échappement pour éviter de synchroniser des blocs de code lorsque cela n'est pas nécessaire.

Dans Java 1.1 , les threads verts étaient le seul modèle de thread utilisé par la machine virtuelle Java (JVM), du moins sur Solaris . Comme les threads verts présentent certaines limitations par rapport aux threads natifs, les versions ultérieures de Java les ont abandonnés au profit des threads natifs.

La machine virtuelle Squawk constitue une exception à cette règle . Il s'agit d'un mélange entre un système d'exploitation pour appareils à faible consommation et une machine virtuelle Java. Elle utilise des threads verts pour minimiser l'utilisation de code natif et pour prendre en charge la migration de ses isolats.

Kilim et Quasar sont des projets open source qui implémentent des threads verts sur les versions ultérieures de la JVM en modifiant le bytecode Java produit par le compilateur Java (Quasar prend également en charge Kotlin et Clojure ).

Il existe d'autres langages de programmation qui implémentent des équivalents de threads verts au lieu de threads natifs. Exemples :

• Chicken Scheme utilise des threads légers au niveau utilisateur basés sur des continuations de première classe
• Lisp commun
• CPython prend en charge nativement asyncio depuis la version 3.4, des implémentations alternatives existent comme greenlet, eventlet et gevent, PyPy
• Le cristal offre des fibres
• D propose des fibres , utilisées pour les E/S asynchrones
• Dyalog APL les appelle threads
• Erlang
• Go implémente ce que l'on appelle des goroutines
• Haskell
• Julia utilise des fils verts pour ses tâches.
• Limbes
• Lua utilise des coroutines pour la concurrence. Lua 5.2 offre également une véritable sémantique de coroutine C grâce aux fonctions lua_yieldk, lua_callk et lua_pcallk. L'extension CoCo permet une véritable sémantique de coroutine C pour Lua 5.1.
• Nim fournit des E/S asynchrones et des coroutines
• OCaml , depuis la version 5.0, prend en charge les threads verts via le module Domainslib.Task
• occam , qui préfère le terme processus au lieu de thread en raison de ses origines dans la communication de processus séquentiels
• Perl prend en charge les threads verts via les coroutines
• PHP prend en charge les threads verts via les fibres et les coroutines
• Ruby avant la version 1.9
• Racket (les threads natifs sont également disponibles via Places )
• Rust prend en charge les threads système de manière native et prend en charge les E/S asynchrones via des bibliothèques tierces comme Tokio
• Mise en œuvre de Concurrent ML par SML/NJ
• Smalltalk (la plupart des dialectes : Squeak , VisualWorks, GNU Smalltalk , etc.)
• Stackless Python prend en charge le multitâche préemptif ou le multitâche coopératif via des microthreads (appelés tasklets ).
• Tcl a des coroutines et une boucle d'événements

La machine virtuelle Erlang possède ce que l'on pourrait appeler des processus verts : ils sont comme les processus du système d'exploitation (ils ne partagent pas d'état comme les threads), mais sont implémentés dans le système d'exécution Erlang (erts). Ceux-ci sont parfois appelés threads verts , mais présentent des différences significatives par rapport aux threads verts standard.

Dans le cas de GHC Haskell, un changement de contexte se produit lors de la première allocation après un délai d'attente configurable. Les threads GHC sont également potentiellement exécutés sur un ou plusieurs threads du système d'exploitation au cours de leur durée de vie (il existe une relation plusieurs-à-plusieurs entre les threads GHC et les threads du système d'exploitation), ce qui permet le parallélisme sur les machines multiprocesseurs symétriques , sans créer de threads du système d'exploitation plus coûteux que nécessaire pour s'exécuter sur le nombre de cœurs disponibles.

La plupart des machines virtuelles Smalltalk ne comptent pas les étapes d'évaluation. Cependant, la machine virtuelle peut toujours préempter le thread en cours d'exécution sur des signaux externes (tels que l'expiration des temporisateurs ou la disponibilité des E/S). En général, la planification à tour de rôle est utilisée pour qu'un processus à priorité élevée qui se réveille régulièrement implémente efficacement la préemption du partage du temps :

[ [( Délai de 
millisecondes : 
50 ) attendre ] répéter ] forkAt : 
Processeur 
highIOPriority

D'autres implémentations, comme QKS Smalltalk, sont toujours en mode partage du temps. Contrairement à la plupart des implémentations de threads verts, QKS prend également en charge la prévention de l'inversion de priorité .

Les threads virtuels ont été introduits en tant que fonctionnalité d'aperçu dans Java 19 et stabilisés dans Java 21. Les différences importantes entre les threads virtuels et les threads verts sont :

• Les threads virtuels coexistent avec les threads de plate-forme et les pools de threads existants (non virtuels).
• Les threads virtuels protègent leur abstraction :
  • Contrairement aux threads verts, dormir sur un thread virtuel ne bloque pas le thread porteur sous-jacent.
  • Le travail avec des variables locales de thread est dévalorisé et les valeurs limitées sont suggérées comme un remplacement plus léger.
• Les threads virtuels peuvent être suspendus et repris à moindre coût, en utilisant le support JVM pour la jdk.internal.vm.Continuationclasse spéciale.
• Les threads virtuels gèrent les appels bloquants en se démontant de manière transparente du thread porteur lorsque cela est possible, sinon en compensant en augmentant le nombre de threads de la plate-forme.