Quelle est la différence technique entre un processus et un fil?
J'ai l'impression qu'un mot comme «processus» est surutilisé et qu'il existe également des fils matériels et logiciels. Qu'en est-il des processus légers dans des langues telles que Erlang ? Existe-t-il une raison définitive d'utiliser un terme plutôt que l'autre?
Les processus et les threads sont des séquences d'exécution indépendantes. La différence typique est que les threads (du même processus) s'exécutent dans un espace mémoire partagé, alors que les processus s'exécutent dans des espaces mémoire séparés.
Je ne suis pas sûr de savoir à quel thread "matériel" ou "logiciel" vous faites allusion. Les threads sont une fonctionnalité de l'environnement d'exploitation plutôt qu'une fonctionnalité du processeur (bien que le processeur effectue généralement des opérations qui rendent les threads efficaces).
Erlang utilise le terme "processus" car il n'expose pas de modèle de multiprogrammation en mémoire partagée. Les appeler "threads" impliquerait qu'ils ont de la mémoire partagée.
Process
Chaque processus fournit les ressources nécessaires à l'exécution d'un programme. Un processus a un espace d'adressage virtuel, un code exécutable, des descripteurs ouverts d'objets système, un contexte de sécurité, un identificateur de processus unique, des variables d'environnement, une classe de priorité, des tailles de jeu minimale et maximale et au moins un thread d'exécution. Chaque processus est démarré avec un seul thread, souvent appelé thread principal, mais peut créer des threads supplémentaires à partir de n'importe lequel de ses threads.
Fil
Un thread est une entité d'un processus qui peut être planifiée pour être exécutée. Tous les threads d'un processus partagent son espace d'adressage virtuel et ses ressources système. En outre, chaque thread gère des gestionnaires d'exception, une priorité de planification, un stockage local du thread, un identificateur de thread unique et un ensemble de structures que le système utilisera pour enregistrer le contexte du thread jusqu'à ce qu'il soit planifié. Le contexte de thread comprend l'ensemble des registres de la machine du thread, la pile du noyau, un bloc d'environnement de thread et une pile d'utilisateurs dans l'espace d'adressage du processus du thread. Les threads peuvent également avoir leur propre contexte de sécurité, qui peut être utilisé pour emprunter l'identité de clients.
Trouvé ceci sur MSDN ici:
À propos des processus et des threads
Microsoft Windows prend en charge le multitâche préemptif, qui crée l’effet de l’exécution simultanée de plusieurs threads à partir de plusieurs processus. Sur un ordinateur multiprocesseur, le système peut exécuter simultanément autant de threads qu'il y a de processeurs sur l'ordinateur.
Processus:
Fil:
J'ai emprunté les informations ci-dessus à la Knowledge Quest! Blog .
Commençons par l’aspect théorique. Vous devez comprendre ce qu'est un processus sur le plan conceptuel pour comprendre la différence entre un processus et un fil et ce qui est partagé entre eux.
La section 2.2.2 présente le modèle de fil classique dans Modern Operating Systems 3e de Tanenbaum:
Le modèle de processus est basé sur deux concepts indépendants: ressource regroupement et exécution. Parfois, il est utile de les séparer; c'est là que les fils entrent en jeu ....
Il continue:
Une façon de considérer un processus est qu’il est une façon de regrouper les ressources connexes. Un processus a un espace d'adressage contenant le texte et les données du programme, ainsi que d’autres ressources. Celles-ci la ressource peut inclure des fichiers ouverts, des processus enfants, des alarmes en attente, gestionnaires de signaux, informations comptables, etc. En les mettant ensemble sous forme de processus, ils peuvent être gérés plus facilement . L'autre concept qu'un processus a est un thread d'exécution, généralement raccourci pour simplement enfiler. Le thread a un compteur de programme qui conserve piste de l'instruction à exécuter ensuite. Il a des registres, qui tenir ses variables de travail actuelles. Il a une pile, qui contient le historique d'exécution, avec un cadre pour chaque procédure appelée mais pas encore revenu de. Bien qu'un thread doive s'exécuter dans un processus, le fichier Le fil et son processus sont des concepts différents et peuvent être traités séparément. Les processus sont utilisés pour regrouper des ressources; fils sont les entités dont l'exécution est planifiée sur la CPU.
Plus bas, il fournit le tableau suivant:
Per process items | Per thread items
------------------------------|-----------------
Address space | Program counter
Global variables | Registers
Open files | Stack
Child processes | State
Pending alarms |
Signals and signal handlers |
Accounting information |
Parlons du problème multithreading matériel . Classiquement, une unité centrale prend en charge un seul thread d'exécution, maintenant son état via un seul compteur de programme et un ensemble de registres. Mais que se passe-t-il s'il y a une cache manquante? Il faut beaucoup de temps pour extraire les données de la mémoire principale et, pendant ce temps, le processeur reste inactif. Ainsi, quelqu'un a eu l'idée de disposer de deux ensembles d'état de threads (registres PC +) afin qu'un autre thread (peut-être dans le même processus, peut-être dans un processus différent) puisse terminer le travail pendant que l'autre thread attend la mémoire principale. Il existe plusieurs noms et implémentations de ce concept, tels que HyperThreading et Multithreading simultané (SMT en abrégé).
Maintenant, regardons le logiciel. Les threads peuvent être implémentés du côté logiciel de trois façons.
Tout ce dont vous avez besoin pour implémenter des threads est la possibilité de sauvegarder l'état de la CPU et de gérer plusieurs piles, ce qui peut souvent être fait dans l'espace utilisateur. L'avantage des threads de l'espace utilisateur est leur commutation très rapide car vous n'avez pas à vous piéger dans le noyau et à la possibilité de planifier vos threads comme vous le souhaitez. L'inconvénient majeur est l'impossibilité de bloquer les E/S (ce qui bloquerait tout le processus et tous ses threads utilisateur), ce qui est l'une des principales raisons pour lesquelles nous utilisons des threads. Le blocage d'E/S à l'aide de threads simplifie grandement la conception de programmes dans de nombreux cas.
Les threads du noyau ont l'avantage de pouvoir utiliser le blocage des E/S, en plus de laisser tous les problèmes de planification au système d'exploitation. Mais chaque commutateur de thread nécessite un interception dans le noyau potentiellement relativement lent. Cependant, si vous changez de threads à cause d'entrées/sorties bloquées, ce n'est pas vraiment un problème car l'opération d'E/S vous a probablement déjà pris au piège dans le noyau.
Une autre approche consiste à combiner les deux, avec plusieurs threads du noyau, chacun ayant plusieurs threads utilisateur.
Donc, pour revenir à votre question de terminologie, vous pouvez voir qu’un processus et un fil d’exécution sont deux concepts différents et que le choix du terme à utiliser dépend de ce dont vous parlez. En ce qui concerne le terme "processus léger", je ne vois pas personnellement l'intérêt de ce processus car il ne dit pas vraiment ce qui se passe ainsi que le terme "fil d'exécution".
Pour en savoir plus sur la programmation simultanée
Un processus a un environnement d'exécution autonome. Un processus a généralement un ensemble complet et privé de ressources d'exécution de base; en particulier, chaque processus a son propre espace mémoire.
Les threads existent dans un processus - chaque processus en a au moins un. Les threads partagent les ressources du processus, y compris la mémoire et les fichiers ouverts. Cela permet une communication efficace mais potentiellement problématique.
Garder la personne moyenne à l'esprit,
Sur votre ordinateur, ouvrez Microsoft Word et votre navigateur Web. Nous appelons ces deux processus .
Dans Microsoft Word, vous tapez quelque chose et il est automatiquement enregistré. Maintenant, vous auriez observé que l'édition et la sauvegarde se déroulent en parallèle - l'édition sur un thread et la sauvegarde sur l'autre.
Une application comprend un ou plusieurs processus. Un processus, dans les termes les plus simples, est un programme d’exécution. Un ou plusieurs threads s'exécutent dans le contexte du processus. Un thread est l'unité de base à laquelle le système d'exploitation attribue le temps processeur. Un thread peut exécuter n'importe quelle partie du code de processus, y compris les parties en cours d'exécution par un autre thread. Une fibre est une unité d'exécution qui doit être programmée manuellement par l'application. Les fibres s'exécutent dans le contexte des threads qui les planifient.
Volé de ici .
Un processus est un ensemble de code, de mémoire, de données et d’autres ressources. Un thread est une séquence de code exécutée dans le cadre du processus. Vous pouvez (généralement) avoir plusieurs threads s'exécutant simultanément dans le même processus.
Processus:
Exemple:
.__ Dites, ouvrez n’importe quel navigateur (Mozilla, Chrome, IE). À ce stade, le nouveau processus va commencer à s'exécuter.
Fils:
Exemple:
Ouverture de plusieurs onglets dans le navigateur.
Les processus et les threads sont des séquences d'exécution indépendantes. La différence typique est que les threads (du même processus) s'exécutent dans un espace mémoire partagé, alors que les processus s'exécutent dans des espaces mémoire séparés.
Processus
Est un programme en exécution. il contient la section de texte, c’est-à-dire le code du programme, l’activité actuelle représentée par la valeur du compteur de programme et le contenu du registre des processeurs. Il inclut également la pile de processus contenant des données temporaires (telles que les paramètres de fonction, les variables de retour adressées et locales) et une section de données contenant des variables globales. Un processus peut également inclure un segment de mémoire, c'est-à-dire une mémoire allouée dynamiquement pendant l'exécution du processus.
Thread
Un thread est une unité de base d'utilisation du processeur; il comprend un identifiant de thread, un compteur de programme, un ensemble de registres et une pile. il a partagé avec d'autres threads appartenant au même processus sa section de code, sa section de données et d'autres ressources du système d'exploitation telles que des fichiers ouverts et des signaux.
- Extrait du système d'exploitation de Galvin
Les threads et les processus sont tous deux des unités atomiques d’allocation de ressources de système d’exploitation (c’est-à-dire qu’il existe un modèle de simultanéité décrivant la façon dont le temps processeur est divisé entre eux et le modèle de possession d’autres ressources de système d’exploitation). Il y a une différence dans:
Greg Hewgill a dit plus haut à propos de la signification du mot "processus" en Erlang. Et ici il y a une discussion sur les raisons pour lesquelles Erlang pourrait utiliser des processus légers.
Différence entre thread et processus?
Un processus est une instance d'exécution d'une application et Un thread est un chemin d'exécution dans un processus. En outre, un processus peut contenir plusieurs threads. Il est important de noter qu’un thread peut faire tout ce qu'un processus peut faire. Mais comme un processus peut comprendre plusieurs threads, un thread peut être considéré comme un processus «léger». Ainsi, la différence essentielle entre un fil et un processus est le travail que chacun est utilisé pour accomplir. Les threads sont utilisés pour de petites tâches, tandis que les processus sont utilisés pour des tâches plus lourdes - essentiellement l'exécution d'applications.
Une autre différence entre un thread et un processus réside dans le fait que les threads d'un même processus partagent le même espace d'adressage, contrairement à différents processus. Cela permet aux threads de lire et d'écrire dans les mêmes structures de données et variables, et facilite également la communication entre les threads. La communication entre processus (également appelée IPC ou communication interprocessus) est assez difficile et nécessite beaucoup de ressources.
Voici un résumé des différences entre les threads et les processus:
Les threads sont plus faciles à créer que les processus car ils ne nécessitent pas d'espace d'adressage séparé.
Le multithreading nécessite une programmation minutieuse car les threads Partagent des structures de données qui ne doivent être modifiées que par un threadà la fois. Contrairement aux threads, les processus ne partagent pas le même espace d'adressage
Les threads sont considérés comme légers car ils utilisent beaucoup moins de ressources que les processus.
Les processus sont indépendants les uns des autres. Les threads, étant donné qu'ils partagent le même espace d'adressage. Ils sont interdépendants. Par conséquent, attention
C’est vraiment une autre façon de dire n ° 2 ci-dessus.
Un processus peut comprendre plusieurs threads.
Essayer de répondre à cette question relative au monde Java.
Un processus est une exécution d'un programme mais un fil est une séquence d'exécution unique dans le processus. Un processus peut contenir plusieurs threads. Un thread est parfois appelé processus poids léger.
Par exemple:
Exemple 1: Une machine virtuelle Java s'exécute dans un processus unique et les threads d'une machine virtuelle partagent le segment de mémoire appartenant à ce processus. C'est pourquoi plusieurs threads peuvent accéder au même objet. Les threads partagent le tas et ont leur propre espace de pile. C’est ainsi que l’appel d’une méthode par un thread et ses variables locales sont préservés des threads. Mais le tas n'est pas thread-safe et doit être synchronisé pour la sécurité des threads.
Exemple 2: Un programme peut ne pas être en mesure de dessiner en lisant les frappes au clavier. Le programme doit accorder toute son attention à la saisie au clavier, sans quoi il sera impossible de gérer plusieurs événements à la fois, ce qui entraînera des problèmes. La solution idéale à ce problème est l’exécution transparente de deux sections ou plus d’un programme en même temps. Les fils nous permettent de le faire. Ici, dessiner une image est un processus et lire une frappe est un sous processus (thread).
Du point de vue de l'interviewer, il y a fondamentalement juste 3 choses que je veux entendre, en plus des choses évidentes comme un processus peut avoir plusieurs threads:
Si vous en voulez plus, la réponse de Scott Langham couvre à peu près tout… .. Tout cela est du point de vue d'un système d'exploitation. Différentes langues peuvent implémenter différents concepts, tels que tâches, threads light-wigh, etc., mais ce ne sont que des façons d'utiliser des threads (de fibres sous Windows) . Il n'y a pas de threads matériels et logiciels. Il existe du matériel et des logiciels exceptions et interruptions , ou en mode utilisateur et kernel threads .
Ce qui suit est ce que j'ai obtenu dans l'un des articles sur The Code Project . Je suppose que cela explique clairement tout ce qui est nécessaire.
Un thread est un autre mécanisme permettant de scinder la charge de travail en fichiers séparés flux d'exécution. Un fil est plus léger qu'un processus. Ce En d'autres termes, il offre moins de souplesse qu'un processus complet, mais peut être lancé plus rapidement car il y a moins pour le système d'exploitation que installer. Quand un programme comprend deux threads ou plus, tous les fichiers les threads partagent un seul espace mémoire. Les processus reçoivent des espaces adresse séparés . tous les threads partagent un seul tas. Mais chaque thread se voit attribuer sa propre pile.
Processus : le programme en cours d'exécution est appelé processus
Thread : Thread est une fonctionnalité exécutée avec l'autre partie du programme sur la base du concept "un avec un autre", de sorte que le thread fait partie du processus.
Venant du monde intégré, je voudrais ajouter que le concept de processus n'existe que dans les "gros" processeurs (processeurs de bureau, ARM Cortex A-9) dotés de MMU (unité de gestion de la mémoire) et les systèmes d'exploitation prenant en charge l'utilisation de MMU (tels que Linux). Avec de petits/anciens processeurs et microcontrôleurs et un petit système d’exploitation RTOS (système d’exploitation en temps réel), tel que freeRTOS, il n’existe pas de support MMU et donc pas de processus, mais uniquement des threads.
Threads peuvent accéder à la mémoire de chacun, et ils sont planifiés par le système d’exploitation de manière entrelacée, de sorte qu’ils semblent fonctionner en parallèle (ou qu’ils fonctionnent réellement en parallèle avec plusieurs coeurs).
Les processus , d’autre part, résident dans leur sandbox privé de mémoire virtuelle, fourni et gardé par MMU. C'est pratique car cela permet:
Pour ceux qui sont plus à l'aise avec l'apprentissage en visualisant, voici un diagramme pratique que j'ai créé pour expliquer Process and Threads.
J'ai utilisé les informations de MSDN - À propos des processus et des threads
Essayer de répondre à partir de la vue OS du noyau Linux
Un programme devient un processus lorsqu'il est lancé en mémoire. Un processus a son propre espace d'adressage, c'est-à-dire qu'il comporte divers segments en mémoire, tels qu'un segment de texte pour stocker le code compilé, un fichier .bss pour stocker des variables statiques ou globales non initialisées, etc. Chaque processus aura son propre compteur de programme et son propre utilisateur pile. À l'intérieur du noyau, chaque processus aurait sa propre pile de noyau (qui est séparée de la pile d'espace utilisateur pour les problèmes de sécurité) et une structure nommée task_struct
qui est généralement abstraite en tant que bloc de contrôle de processus, stockant toutes les informations concernant le processus, telles que sa priorité. état, et beaucoup d'autres morceaux. Un processus peut avoir plusieurs threads d'exécution.
Venant aux threads, ils résident dans un processus et partagent l'espace d'adressage du processus parent ainsi que d'autres ressources pouvant être transmises lors de la création de threads, telles que les ressources de système de fichiers, le partage des signaux en attente, le partage de données (variables et instructions), ce qui rend les threads légers et permettant ainsi un changement de contexte plus rapide. Dans le noyau, chaque thread a sa propre pile de noyau ainsi que la structure task_struct
qui définit le thread. Par conséquent, le noyau considère les threads du même processus comme des entités différentes et sont planifiés en eux-mêmes. Les threads d'un même processus partagent un identifiant commun appelé identifiant de groupe de threads (tgid
). Ils ont également un identifiant unique appelé identifiant de processus (pid
).
Lors de la construction d'un algorithme en Python (langage interprété) intégrant le multi-threading, j'ai été surpris de constater que le temps d'exécution n'était pas meilleur par rapport à l'algorithme séquentiel que j'avais précédemment construit. Dans un effort pour comprendre la raison de ce résultat, j'ai lu un peu, et je pense que ce que j'ai appris offre un contexte intéressant pour mieux comprendre les différences entre le multi-threading et le multi-processus.
Les systèmes multicœurs peuvent exercer plusieurs threads d’exécution, aussi Python devrait-il prendre en charge le multi-threading. Mais Python n'est pas un langage compilé mais un langage interprété1. Cela signifie que le programme doit être interprété pour pouvoir être exécuté et que l'interpréteur n'a pas connaissance du programme avant qu'il ne commence à s'exécuter. Cependant, ce qu'il sait, ce sont les règles de Python et il les applique ensuite de manière dynamique. Les optimisations en Python doivent alors être principalement des optimisations de l'interpréteur lui-même et non du code à exécuter. Cela contraste avec les langages compilés tels que C++ et a des conséquences sur le multi-threading en Python. Plus précisément, Python utilise le verrou d'interprète global pour gérer le multi-threading.
D'autre part, un langage compilé est, eh bien, compilé. Le programme est traité "entièrement", où il est d'abord interprété conformément à ses définitions syntaxiques, puis mappé sur une représentation intermédiaire indépendante du langage, puis lié à un code exécutable. Ce processus permet d’optimiser considérablement le code car il est disponible au moment de la compilation. Les diverses interactions et relations du programme sont définies au moment de la création de l’exécutable et permettent de prendre des décisions éclairées en matière d’optimisation.
Dans les environnements modernes, l'interpréteur de Python doit permettre le multi-threading, qui doit être à la fois sûr et efficace. C’est là que la différence entre être un langage interprété et un langage compilé entre en scène. L'interprète ne doit pas perturber en interne les données partagées provenant de différents threads, tout en optimisant l'utilisation de processeurs pour les calculs.
Comme il a été noté dans les publications précédentes, un processus et un thread sont des exécutions séquentielles indépendantes, la principale différence étant que la mémoire est partagée entre plusieurs threads d'un processus, tandis que les processus isolent leurs espaces mémoire.
En Python, les données sont protégées contre les accès simultanés de différents threads par le verrou d'interpréteur global. Cela nécessite que dans tout programme Python, un seul thread puisse être exécuté à tout moment. D'autre part, il est possible d'exécuter plusieurs processus car la mémoire de chaque processus est isolée de tout autre processus et les processus peuvent s'exécuter sur plusieurs cœurs.
1 Donald Knuth a une bonne explication des routines d'interprétation dans L'Art de la programmation informatique: algorithmes fondamentaux.
Les threads d'un même processus partagent la mémoire, mais chaque thread a sa propre pile et ses propres registres, et les threads stockent des données spécifiques au thread dans le tas. Les threads ne s'exécutant jamais de manière indépendante, la communication inter-thread est beaucoup plus rapide que la communication inter-processus.
Les processus ne partagent jamais la même mémoire. Lorsqu'un processus enfant créé, il duplique l'emplacement de la mémoire du processus parent. La communication de processus s'effectue à l'aide d'un canal, de la mémoire partagée et de l'analyse de messages. La commutation de contexte entre les threads est très lente.
Meilleure réponse
Processus:
Le processus est fondamentalement un programme en exécution. C’est une entité active . Certains systèmes d’exploitation utilisent le terme 'tâche' pour désigner un programme en cours d’exécution . Un processus est toujours stocké dans la mémoire principale, également appelée mémoire principale ou mémoire vive. . Par conséquent, un processus est appelé une entité active. Il disparaît si la machine est redémarrée . Plusieurs processus peuvent être associés à un même programme . Sur un système multiprocesseur, plusieurs processus peuvent être exécutés en parallèle . Sur un système mono-processeur, bien que le parallélisme soit vrai n’est pas atteint, un algorithme de planification de processus est appliqué et le processeur est planifié pour exécuter chaque processus un par un, ce qui donne une illusion de simultanéité ..__ Exemple: Exécution de plusieurs instances du programme 'Calculatrice'. Chacune des instances est appelée processus.
Fil:
Un thread est un sous-ensemble du processus . Il est appelé «processus léger», car il est similaire à un processus réel mais s'exécute dans le contexte d'un processus et partage les mêmes ressources allouées au processus par le noyau. . Généralement, un processus ne comporte qu'un seul thread de contrôle - un ensemble d'instructions machine s'exécutant à la fois . Un processus peut également être constitué de plusieurs threads d'exécution exécutant simultanément des instructions . Le contrôle peut exploiter le vrai parallélisme possible sur les systèmes multiprocesseurs . Sur un système mono-processeur, un algorithme de planification de threads est appliqué et le processeur est planifié pour exécuter chaque thread un à la fois . Tous les threads exécutés dans un processus partage le même espace d'adressage, les descripteurs de fichier, la pile et d'autres attributs liés au processus . Étant donné que les threads d'un processus partagent la même mémoire, la synchronisation de l'accès aux données partagées avec le processus revêt une importance sans précédent.
ref - https://practice.geeksforgeeks.org/problems/difference-between-process-and-thread
Ils sont presque identiques ... Mais la différence principale est qu'un fil est léger et qu'un processus est lourd en termes de changement de contexte, de charge de travail, etc.
La différence entre processus et thread est donnée ci-dessous:
La meilleure réponse que j'ai trouvée jusqu'à présent est L'interface de programmation Linux de Michael Kerrisk :
Dans les implémentations UNIX modernes, chaque processus peut avoir plusieurs threads d'exécution. Une façon d'envisager les threads consiste à utiliser un ensemble de processus qui partagent la même mémoire virtuelle, ainsi qu'une gamme d'autres les attributs. Chaque thread exécute le même code de programme et partage le même fichier la même zone de données et tas. Cependant, chaque thread a sa propre pile contenant des variables locales et des informations de liaison d’appel de fonction. [LPI 2.12]
Ce livre est une source de grande clarté. Julia Evans a mentionné son aide pour clarifier le fonctionnement réel des groupes Linux dans cet article .
Exemple 1: une machine virtuelle Java s'exécute dans un seul processus et les threads d'une machine virtuelle partagent le segment de mémoire appartenant à ce processus. C'est pourquoi plusieurs threads peuvent accéder au même objet. Les threads partagent le tas et ont leur propre espace de pile. C’est ainsi que l’appel d’une méthode par un thread et ses variables locales sont préservés des threads. Mais le tas n'est pas thread-safe et doit être synchronisé pour la sécurité des threads.
Considérons un processus comme une unité de propriété ou les ressources nécessaires à une tâche. Un processus peut avoir des ressources telles que de la mémoire, des entrées/sorties spécifiques, des fichiers spécifiques, des priorités, etc.
Un thread est une unité d'exécution dispatchable ou en mots simples la progression dans une séquence d'instructions
J'ai lu presque toutes les réponses, hélas, en tant qu'étudiant de premier cycle qui suit un cours sur l'OS, je ne peux pas comprendre complètement les deux concepts. Je veux dire que la plupart des gars lisent dans certains livres d’exploitation les différences, c’est-à-dire que les threads peuvent accéder aux variables globales dans l’unité de transaction car ils utilisent l’espace adresse de leur processus. Cependant, la nouvelle question se pose de savoir pourquoi il y a des processus, sachant que nous savons déjà que les fils sont plus légers que les processus. Regardons l'exemple suivant en utilisant l'image extraite de une des réponses précédentes ,
Nous avons 3 threads travaillant à la fois sur un document Word, par exemple. Libre Office . Le premier vérifie l'orthographe en soulignant si la Parole est mal orthographiée. La seconde prend et imprime les lettres du clavier. Et le dernier sauvegarde le document à chaque fois afin de ne pas perdre le document si quelque chose ne va pas. Dans ce cas, les 3 threads ne peuvent pas être 3 processus car ils partagent une mémoire commune qui est l'espace d'adressage de leur processus et ont donc tous accès au document en cours d'édition. Donc, la route est le document Word avec deux bulldozers qui constituent le fil conducteur, même s’il manque un dans l’image.
De Erlang Programming (2009): La simultanéité d'Erlang est rapide et évolutive. Ses processus sont légers en ce que la machine virtuelle Erlang ne crée pas de thread de système d'exploitation pour chaque processus créé. Ils sont créés, planifiés et gérés dans la machine virtuelle, indépendamment du système d'exploitation sous-jacent.
Erlang implémente un planificateur préemptif, qui permet à chaque processus de s'exécuter pendant une période de temps définie sans bloquer trop longtemps un thread système, ce qui donne à chaque processus un certain temps à exécuter. Le nombre de threads système dépend du nombre de cœurs si je ne me trompe pas. Les processus peuvent être supprimés d'un thread et déplacés vers un autre si la charge devient inégale. Tout cela est géré par le planificateur Erlang.