Quelle est la différence entre un processus et un thread?

Quelle est la différence technique entre un processus et un thread?

J'ai l'impression qu'un mot comme «processus» est surutilisé et qu'il existe également des threads matériels et logiciels. Qu'en est-il des processus légers dans des langues comme Erlang ? Y a-t-il une raison définitive d'utiliser un terme plutôt qu'un 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é, tandis que les processus s'exécutent dans des espaces mémoire séparés.

Je ne sais pas à quels threads "matériel" vs "logiciel" vous faites peut-être référence. Les threads sont une fonctionnalité de l'environnement d'exploitation, plutôt qu'une fonctionnalité du CPU (bien que le CPU ait généralement des opérations qui rendent les threads efficaces).

Erlang utilise le terme "processus" car il n'expose pas un modèle de multiprogrammation à mémoire partagée. Les appeler "threads" impliquerait qu'ils ont une mémoire partagée.

Processus
Chaque processus fournit les ressources nécessaires pour exécuter un programme. Un processus a un espace d'adressage virtuel, du code exécutable, des descripteurs ouverts pour les 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 de travail minimales et maximales et au moins un thread d'exécution. Chaque processus est démarré avec un seul thread, souvent appelé le 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 dont l'exécution peut être planifiée. Tous les threads d'un processus partagent son espace d'adressage virtuel et ses ressources système. De plus, chaque thread conserve des gestionnaires d'exceptions, une priorité de planification, un stockage local de thread, un identifiant de thread unique et un ensemble de structures que le système utilisera pour enregistrer le contexte de thread jusqu'à ce qu'il soit planifié. Le contexte de thread inclut l'ensemble des registres de machine du thread, la pile du noyau, un bloc d'environnement de thread et une pile d'utilisateur 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é des clients.

Ces informations ont été trouvées sur Microsoft Docs ici: À propos des processus et des threads

Microsoft Windows prend en charge le multitâche préemptif, ce 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:

• Une instance d'exécution d'un programme est appelée un processus.
• 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é mémoire principale ou mémoire à accès aléatoire.
• Par conséquent, un processus est qualifié d'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 monoprocesseur, bien que le véritable parallélisme ne soit pas atteint, un algorithme de planification de processus est appliqué et le processeur est planifié pour exécuter chaque processus un à la fois, ce qui donne une illusion de concurrence.
• Exemple: exécution de plusieurs instances du programme «Calculatrice». Chacune des instances est qualifiée de processus.

Fil:

• Un thread est un sous-ensemble du processus.
• Il est qualifié de «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.
• Habituellement, un processus n'a qu'un seul thread de contrôle - un ensemble d'instructions machine s'exécutant à la fois.
• Un processus peut également être composé de plusieurs threads d'exécution qui exécutent des instructions simultanément.
• Plusieurs threads de contrôle peuvent exploiter le véritable parallélisme possible sur les systèmes multiprocesseurs.
• Sur un système à processeur unique, un algorithme de planification des threads est appliqué et le processeur est planifié pour exécuter chaque thread un par un.
• Tous les threads s'exécutant dans un processus partagent le même espace d'adressage, descripteurs de fichiers, pile et 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 au sein du processus acquiert une importance sans précédent.

J'ai emprunté les informations ci-dessus à la quête de connaissances! blog .

Voyons d'abord 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 thread et ce qui est partagé entre eux.

Nous avons les éléments suivants de la section 2.2.2 Le modèle de fil classique dans les systèmes d'exploitation modernes 3e de Tanenbaum:

Le modèle de processus est basé sur deux concepts indépendants: le regroupement et l'exécution des ressources. Parfois, il est utile de les séparer; c'est là que les fils entrent en jeu ....

Il continue:

Une façon d'envisager un processus est qu'il s'agit d'un moyen de regrouper des ressources connexes. Un processus possède un espace d'adressage contenant le texte et les données du programme, ainsi que d'autres ressources. Ces ressources peuvent inclure des fichiers ouverts, des processus enfants, des alarmes en attente, des gestionnaires de signaux, des informations comptables, etc. En les regroupant sous forme de processus, ils peuvent être gérés plus facilement. L'autre concept d'un processus est un thread d'exécution, généralement abrégé en juste thread. Le thread a un compteur de programme qui garde la trace de l'instruction à exécuter ensuite. Il a des registres, qui contiennent ses variables de travail actuelles. Il a une pile, qui contient l'historique d'exécution, avec une trame pour chaque procédure appelée mais pas encore retournée. Bien qu'un thread doive s'exécuter dans un processus, 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 les ressources; les threads sont les entités dont l'exécution est planifiée sur le processeur.

Plus loin, 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        |

Traitons le problème du multithreading matériel . Classiquement, un CPU prend en charge un seul thread d'exécution, maintenant l'état du thread via un seul compteur de programme et un ensemble de registres. Mais que se passe-t-il s'il y a un échec de cache? Il faut beaucoup de temps pour extraire des données de la mémoire principale, et pendant ce temps, le processeur reste juste inactif. Donc, quelqu'un a eu l'idée d'avoir essentiellement deux ensembles d'état de thread (registres PC +) afin qu'un autre thread (peut-être dans le même processus, peut-être dans un processus différent) puisse faire le travail pendant que l'autre thread attend dans la mémoire principale. Il existe plusieurs noms et implémentations de ce concept, comme HyperThreading et Simultaneous Multithreading (SMT pour faire court).

Voyons maintenant le côté logiciel. Il existe essentiellement trois façons d'implémenter les threads du côté logiciel.

1. Threads de l'espace utilisateur
2. Threads du noyau
3. Une combinaison des deux

Tout ce dont vous avez besoin pour implémenter les threads est la possibilité d'enregistrer l'état du processeur et de conserver plusieurs piles, ce qui peut dans de nombreux cas être effectué dans l'espace utilisateur. L'avantage des threads de l'espace utilisateur est la commutation de threads ultra rapide car vous n'avez pas à vous coincer dans le noyau et la possibilité de planifier vos threads comme vous le souhaitez. Le plus gros inconvénient est l'incapacité à bloquer les E / S (ce qui bloquerait l'ensemble du processus et tous ses threads utilisateur), ce qui est l'une des principales raisons pour lesquelles nous utilisons des threads en premier lieu. Le blocage des E / S à l'aide de threads simplifie considérablement la conception du programme dans de nombreux cas.

Les threads du noyau ont l'avantage de pouvoir utiliser les E / S de blocage, en plus de laisser tous les problèmes de planification au système d'exploitation. Mais chaque changement de thread nécessite un piégeage dans le noyau qui est potentiellement relativement lent. Cependant, si vous changez de threads en raison d'E / S bloquées, ce n'est pas vraiment un problème car l'opération d'E / S vous a probablement déjà piégé dans le noyau.

Une autre approche consiste à combiner les deux, avec plusieurs threads du noyau ayant chacun plusieurs threads utilisateur.

Pour en 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 n'y vois personnellement pas l'intérêt car il ne traduit pas vraiment ce qui se passe ainsi que le terme "fil d'exécution".

Pour en savoir plus sur la programmation simultanée

1. Un processus possède un environnement d'exécution autonome. Un processus possède 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.

2. 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 rend la communication efficace, mais potentiellement problématique.

Gardant à l'esprit la personne moyenne,

Sur votre ordinateur, ouvrez Microsoft Word et 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 l'enregistrement se produisent en parallèle - l'édition sur un thread et l'enregistrement sur l'autre thread.

Une application comprend un ou plusieurs processus. Un processus, dans les termes les plus simples, est un programme en cours 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 alloue le temps processeur. Un thread peut exécuter n'importe quelle partie du code de processus, y compris les parties actuellement exécutées par un autre thread. Une fibre est une unité d'exécution qui doit être planifiée manuellement par l'application. Les fibres s'exécutent dans le contexte des threads qui les planifient.

Volé d' ici .

Un processus est une collection de code, de mémoire, de données et d'autres ressources. Un thread est une séquence de code qui est 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.

Exemple réel pour Process et Thread Cela vous donnera une idée de base sur le thread et le processus

J'ai emprunté les informations ci-dessus à la réponse de Scott Langham - merci

Processus:

1. Le processus est un processus lourd.
2. Le processus est un programme distinct qui a une mémoire, des données et des ressources distinctes.
3. Les processus sont créés à l'aide de la méthode fork ().
4. Le changement de contexte entre les processus prend du temps.
   

Exemple: par exemple
, en ouvrant n'importe quel navigateur (mozilla, Chrome, IE). À ce stade, un nouveau processus commencera à s'exécuter.

Fils:

1. Les threads sont des processus légers. Les threads sont regroupés à l'intérieur du processus.
2. Les threads ont une mémoire partagée, des données, des ressources, des fichiers, etc.
3. Les threads sont créés à l'aide de la méthode clone ().
4. Le changement de contexte entre les threads ne prend pas beaucoup de temps en tant que processus.
   

Exemple:
ouverture de plusieurs onglets dans le navigateur.

• Chaque processus est un thread (thread principal).
• Mais chaque thread n'est pas un processus. C'est une partie (entité) d'un processus.

Les threads et les processus sont des unités atomiques d'allocation des ressources du système d'exploitation (c'est-à-dire qu'il existe un modèle de concurrence décrivant la façon dont le temps CPU est divisé entre eux, et le modèle de possession d'autres ressources du système d'exploitation). Il y a une différence dans:

• Ressources partagées (les threads partagent la mémoire par définition, ils ne possèdent rien sauf la pile et les variables locales; les processus peuvent également partager la mémoire, mais il existe un mécanisme distinct pour cela, maintenu par le système d'exploitation)
• Espace d'allocation (espace noyau pour les processus vs espace utilisateur pour les threads)

Greg Hewgill ci-dessus avait raison sur la signification d'Erlang du mot "processus", et ici il y a une discussion sur la raison pour laquelle Erlang pourrait faire des processus légers.

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é, tandis que les processus s'exécutent dans des espaces mémoire séparés.

Processus

Est un programme en cours d'exécution. il a une section de texte, c'est-à-dire le code du programme, l'activité actuelle telle que représentée par la valeur du compteur de programme et le contenu du registre des processeurs. Il comprend également la pile de processus qui contient des données temporaires (telles que les paramètres de fonction, les variables renvoyées et locales) et une section de données, qui contient des variables globales. Un processus peut également inclure un segment de mémoire, qui est une mémoire allouée dynamiquement pendant l'exécution du processus.

Fil

Un thread est une unité de base d'utilisation du CPU; il comprend un ID de thread, un compteur de programme, un ensemble de registres et une pile. il partageait 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 les fichiers ouverts et les signaux.

- Tiré du système d'exploitation par Galvin

http://lkml.iu.edu/hypermail/linux/kernel/9608/0191.html

Linus Torvalds (torvalds@cs.helsinki.fi)

Mar., 6 août 1996 12:47:31 +0300 (EET DST)

Messages triés par: [date] [thread] [sujet] [auteur]

Message suivant: Bernd P. Ziller: "Re: Oups dans get_hash_table"

Message précédent: Linus Torvalds: "Re: commande de demande d'E / S"

Le lundi 5 août 1996, Peter P. Eiserloh a écrit:

Nous devons garder clair le concept de threads. Trop de gens semblent confondre un fil avec un processus. La discussion suivante ne reflète pas l'état actuel de Linux, mais est plutôt une tentative de rester à une discussion de haut niveau.

NON!

Il n'y a AUCUNE raison de penser que les «fils» et les «processus» sont des entités distinctes. C'est ainsi que cela se fait traditionnellement, mais je pense personnellement que c'est une erreur majeure de penser de cette façon. La seule raison de penser de cette façon est le bagage historique.

Les threads et les processus ne sont en réalité qu'une seule chose: un "contexte d'exécution". Essayer de distinguer artificiellement différents cas est tout simplement autolimitant.

Un «contexte d'exécution», ci-après appelé COE, n'est que le conglomérat de tout l'état de ce COE. Cet état comprend des éléments comme l'état du processeur (registres, etc.), l'état MMU (mappages de pages), l'état d'autorisation (uid, gid) et divers "états de communication" (fichiers ouverts, gestionnaires de signaux, etc.). Traditionnellement, la différence entre un "thread" et un "processus" a été principalement qu'un thread a un état CPU (+ éventuellement un autre état minimal), tandis que tout le reste du contexte provient du processus. Cependant, ce n'est qu'une façon de diviser l'état total du COE, et rien ne dit que c'est la bonne façon de le faire. Se limiter à ce genre d'image est tout simplement stupide.

La façon dont Linux pense à ce sujet (et la façon dont je veux que les choses au travail) est qu'il n'y a pas une telle chose comme un « processus » ou un « fil ». Il n'y a que la totalité du COE (appelé «tâche» par Linux). Différents COE peuvent partager des parties de leur contexte entre eux, et un sous-ensemble - de ce partage est la configuration traditionnelle "thread" / "processus", mais cela devrait vraiment être considéré comme SEULEMENT un sous-ensemble (c'est un sous-ensemble important, mais cette importance vient pas de conception, mais de normes: nous voulons évidemment exécuter des programmes de threads conformes aux normes sur Linux aussi).

En bref: ne concevez PAS autour de la façon de penser fil / processus. Le noyau doit être conçu autour de la façon de penser COE, puis la bibliothèque pthreads peut exporter l'interface pthreads limitée aux utilisateurs qui souhaitent utiliser cette façon de voir les COE.

Juste comme un exemple de ce qui devient possible lorsque vous pensez COE par opposition à thread / processus:

• Vous pouvez faire un programme "cd" externe, quelque chose qui est traditionnellement impossible sous UNIX et / ou process / thread (exemple idiot, mais l'idée est que vous pouvez avoir ce genre de "modules" qui ne sont pas limités à l'UNIX traditionnel / configuration des threads). Fait une:

clone (CLONE_VM | CLONE_FS);

enfant: execve ("external-cd");

/ * le "execve ()" dissociera la VM, donc la seule raison pour laquelle nous avons utilisé CLONE_VM était d'accélérer le clonage * /

• Vous pouvez faire "vfork ()" naturellement (cela nécessite un support minimal du noyau, mais ce support correspond parfaitement à la façon de penser de l'AUC):

clone (CLONE_VM);

enfant: continuer à courir, éventuellement execve ()

mère: attendez execve

• vous pouvez faire des "démons IO" externes:

clone (CLONE_FILES);

enfant: descripteurs de fichiers ouverts, etc.

mère: utilisez le fd de l'enfant ouvert et vv.

Tout ce qui précède fonctionne parce que vous n'êtes pas lié à la façon de penser du fil / processus. Pensez à un serveur web par exemple, où les scripts CGI se font comme des "threads d'exécution". Vous ne pouvez pas faire cela avec des threads traditionnels, car les threads traditionnels doivent toujours partager tout l'espace d'adressage, vous devez donc lier tout ce que vous avez toujours voulu faire dans le serveur Web lui-même (un «thread» ne peut pas s'exécuter un autre exécutable).

En considérant cela comme un problème de "contexte d'exécution", vos tâches peuvent désormais choisir d'exécuter des programmes externes (= séparer l'espace d'adressage du parent), etc. si elles le souhaitent, ou elles peuvent par exemple tout partager avec le parent, sauf pour les descripteurs de fichiers (pour que les sous-"threads" puissent ouvrir beaucoup de fichiers sans que le parent ait à s'en soucier: ils se ferment automatiquement lorsque le sous-"thread" se termine, et il n'utilise pas les fd dans le parent) .

Pensez à un "inetd" fileté, par exemple. Vous voulez un faible overhead fork + exec, donc avec la méthode Linux vous pouvez au lieu d'utiliser un "fork ()" vous écrivez un inetd multi-thread où chaque thread est créé avec juste CLONE_VM (partager l'espace d'adressage, mais ne pas partager le fichier descripteurs, etc.). L'enfant peut alors s'exécuter s'il s'agissait d'un service externe (rlogind, par exemple), ou peut-être qu'il s'agissait d'un des services internes inetd (echo, timeofday), auquel cas il fait simplement sa chose et se termine.

Vous ne pouvez pas faire cela avec "thread" / "processus".

Linus

Essayer d'y 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, ce qui signifie qu'il a divers segments en mémoire tels que le .textsegment pour stocker le code compilé, .bsspour stocker des variables statiques ou globales non initialisées, etc.
Chaque processus aurait son propre compteur de programme et sa propre pile d' espace utilisateur .

À l'intérieur du noyau, chaque processus aurait sa propre pile de noyau (qui est séparée de la pile de l'espace utilisateur pour des problèmes de sécurité) et une structure nommée task_structqui 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é, son état , (et beaucoup d'autres morceaux).
Un processus peut avoir plusieurs threads d'exécution.

En ce qui concerne les threads, ils résident dans un processus et partagent l'espace d'adressage du processus parent avec d'autres ressources qui peuvent être transmises lors de la création de threads telles que les ressources du système de fichiers, le partage de 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.

A l'intérieur du noyau, chaque thread a sa propre pile de noyau ainsi que la task_structstructure qui définit le thread. Par conséquent, le noyau affiche les threads du même processus que différentes entités et sont programmables en eux-mêmes. Les threads du même processus partagent un identifiant commun appelé id de groupe de threads ( tgid), ils ont également un identifiant unique appelé id de processus ( pid).

Essayer de répondre à cette question relative au monde Java.

Un processus est une exécution d'un programme mais un thread est une séquence d'exécution unique au sein du processus. Un processus peut contenir plusieurs threads. Un thread est parfois appelé un processus léger .

Par exemple:

Exemple 1: une JVM s'exécute dans un seul processus et les threads d'une JVM partagent le segment 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'invocation par un thread d'une méthode et ses variables locales sont conservées à l'abri des autres 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 des images en lisant les touches. Le programme doit accorder toute son attention à la saisie au clavier et le fait de ne pas pouvoir gérer plus d'un événement à la fois 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. Threads nous permet de le faire. Ici, l'image de dessin est un processus et la lecture de la touche est un sous-processus (thread).

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 au sein d'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 être composé de 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 les petites tâches, tandis que les processus sont utilisés pour les tâches plus «lourdes» - essentiellement l'exécution des applications.

Une autre différence entre un thread et un processus est que les threads d'un même processus partagent le même espace d'adressage, contrairement à des processus différents. 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 les processus - également appelée IPC, ou communication inter-processus - est assez difficile et gourmande en ressources.

Voici un résumé des différences entre les threads et les processus:

1. Les threads sont plus faciles à créer que les processus car ils ne nécessitent pas d'espace d'adressage séparé.

2. 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.

3. Les threads sont considérés comme légers car ils utilisent beaucoup moins de ressources que les processus.

4. Les processus sont indépendants les uns des autres. Les threads, car ils partagent le même espace d'adressage, sont interdépendants, il faut donc être prudent afin que les différents threads ne se piétinent pas.
   C'est vraiment une autre façon d'énoncer # 2 ci-dessus.

5. Un processus peut être composé de plusieurs threads.

Voici ce que j'ai obtenu d'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 pour diviser la charge de travail en flux d'exécution distincts. Un fil est plus léger qu'un processus. Cela signifie qu'il offre moins de flexibilité qu'un processus complet, mais peut être lancé plus rapidement car le système d'exploitation a moins à configurer. Lorsqu'un programme se compose de deux ou plusieurs threads, tous les threads partagent un seul espace mémoire. Les processus reçoivent des espaces d'adressage distincts. tous les threads partagent un seul tas. Mais chaque thread a sa propre pile.

Processus:

Le processus est essentiellement un programme en cours d'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é mémoire principale ou mémoire à accès aléatoire. Par conséquent, un processus est qualifié d'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 monoprocesseur, bien que le véritable parallélisme ne soit pas atteint, un algorithme de planification de processus est appliqué et le processeur est planifié pour exécuter chaque processus un à la fois, ce qui donne une illusion de concurrence. Exemple: exécution de plusieurs instances du programme «Calculatrice». Chacune des instances est qualifiée de processus.

Fil:

Un thread est un sous-ensemble du processus. Il est qualifié de «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. Habituellement, un processus n'a qu'un seul thread de contrôle - un ensemble d'instructions machine s'exécutant à la fois. Un processus peut également être composé de plusieurs threads d'exécution qui exécutent des instructions simultanément. Plusieurs threads de contrôle peuvent exploiter le véritable parallélisme possible sur les systèmes multiprocesseurs. Sur un système à processeur unique, un algorithme de planification de threads est appliqué et le processeur est planifié pour exécuter chaque thread un par un. Tous les threads s'exécutant dans un processus partagent le même espace d'adressage, descripteurs de fichiers, pile et autres attributs liés au processus. Étant donné que les threads d'un processus partagent la même mémoire,

ref- https://practice.geeksforgeeks.org/problems/difference-between-process-and-thread

Du point de vue d'un intervieweur, il y a fondamentalement seulement 3 choses principales que je veux entendre, en plus des choses évidentes comme un processus peut avoir plusieurs fils:

1. Les threads partagent le même espace mémoire, ce qui signifie qu'un thread peut accéder à la mémoire à partir de la mémoire d'un autre thread. Les processus ne peuvent normalement pas.
2. Ressources. Les ressources (mémoire, poignées, sockets, etc.) sont libérées à la fin du processus, et non à la fin du thread.
3. Sécurité. Un processus a un jeton de sécurité fixe. Un thread, d'autre part, peut emprunter l'identité de différents utilisateurs / jetons.

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, comme les tâches, les threads légers et ainsi de suite, mais ce ne sont que des façons d'utiliser les threads (des fibres sur Windows). Il n'y a pas de threads matériels et logiciels. Il existe des exceptions et des interruptions matérielles et logicielles , ou des threads en mode utilisateur et du noyau .

1. Un thread s'exécute dans un espace mémoire partagé, mais un processus s'exécute dans un espace mémoire séparé
2. Un fil est un processus léger, mais un processus est un processus lourd.
3. Un thread est un sous-type de processus.

Pour ceux qui sont plus à l'aise avec l'apprentissage par la visualisation, voici un diagramme pratique que j'ai créé pour expliquer le processus et les threads.
J'ai utilisé les informations de MSDN - À propos des processus et des threads

Venant du monde embarqué, je voudrais ajouter que le concept de processus n'existe que dans les "gros" processeurs ( CPU de bureau, ARM Cortex A-9 ) qui ont MMU (unité de gestion de mémoire), et les systèmes d'exploitation qui prennent en charge l'utilisation de MMU ( comme Linux ). Avec les petits / anciens processeurs et microcontrôleurs et le petit système d'exploitation RTOS (système d'exploitation en temps réel ), comme freeRTOS, il n'y a pas de support MMU et donc pas de processus mais seulement des threads.

Les threads peuvent accéder à la mémoire de l'autre, 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 avec le multicœur, ils s'exécutent vraiment en parallèle).

Les processus , en revanche, vivent dans leur sandbox privé de mémoire virtuelle, fourni et gardé par MMU. Ceci est pratique car il permet:

1. empêcher le processus de buggy de planter le système entier.
2. Maintenir la sécurité en rendant d'autres données de processus invisibles et inaccessibles. Le travail réel à l'intérieur du processus est pris en charge par un ou plusieurs threads.

1. Fondamentalement, un thread fait partie d'un processus sans thread de processus ne pourrait pas fonctionner.
2. Un fil est léger alors que le processus est lourd.
3. la communication entre les processus nécessite un certain temps tandis que le thread nécessite moins de temps.
4. Les threads peuvent partager la même zone de mémoire tandis que le processus vit séparément.

Processus : le programme en cours d'exécution est appelé processus

Thread : Thread est une fonctionnalité qui est exécutée avec l'autre partie du programme sur la base du concept de "l'un avec l'autre", donc le thread fait partie du processus.

J'ai lu presque toutes les réponses là-bas, hélas, en tant qu'étudiant de premier cycle qui suit actuellement 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 OS les différences, c'est-à-dire que les threads sont capables d'accéder aux variables globales dans l'unité de transaction car ils utilisent l'espace d'adressage de leur processus. Pourtant, la nouvelle question se pose de savoir pourquoi il existe des processus, sachant que nous savons déjà que les threads sont plus légers vis-à-vis des processus. Jetons un coup d'œil à l'exemple suivant en utilisant l'image extraite d' 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 le mot est mal orthographié. Le second prend et imprime les lettres du clavier. Et le dernier enregistre le document en peu de temps pour ne pas perdre le document travaillé en cas de problème. 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. Ainsi, la route est le mot document avec deux bulldozers qui sont les fils même si l'un d'eux manque d'image.

Lors de la construction d'un algorithme en Python (langage interprété) qui incorporait le multithread, j'ai été surpris de voir 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 fait quelques lectures et je crois que ce que j'ai appris offre un contexte intéressant à partir duquel 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, et donc Python devrait prendre en charge le multithread. Mais Python n'est pas un langage compilé et est plutôt un langage interprété ¹ . Cela signifie que le programme doit être interprété pour s'exécuter et que l'interpréteur n'est pas au courant du programme avant de commencer son exécution. Ce qu'il sait, cependant, ce sont les règles de Python et il applique ensuite dynamiquement ces règles. 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 pour le multi-threading en Python. Plus précisément, Python utilise le Global Interpreter Lock pour gérer le multithread.

D'un autre côté, un langage compilé est, bien, compilé. Le programme est traité "entièrement", où il est d'abord interprété selon ses définitions syntaxiques, puis mappé à une représentation intermédiaire indépendante du langage, et enfin lié en un code exécutable. Ce processus permet au code d'être hautement optimisé car il est entièrement 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 des décisions solides concernant l'optimisation peuvent être prises.

Dans les environnements modernes, l'interpréteur de Python doit permettre le multi-threading, et cela doit être à la fois sûr et efficace. C'est là que la différence entre être une langue interprétée et une langue compilée entre en scène. L'interpréteur ne doit pas perturber les données partagées en interne à partir de différents threads, tout en optimisant l'utilisation des processeurs pour les calculs.

Comme cela a été noté dans les articles précédents, 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 l'accès simultané par différents threads par le Global Interpreter Lock. Cela nécessite que dans n'importe quel 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.

¹ Donald Knuth a une bonne explication des routines d'interprétation dans The Art of Computer Programming: Fundamental Algorithms.

Les threads du 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écutent jamais indépendamment, la communication inter-threads est donc beaucoup plus rapide que la communication inter-processus.

Les processus ne partagent jamais la même mémoire. Lorsqu'un processus enfant crée, il duplique l'emplacement mémoire du processus parent. La communication des processus se fait à l'aide de canaux, de mémoire partagée et d'analyse de messages. La commutation de contexte entre les threads est très lente.

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 est un ensemble de processus qui partagent la même mémoire virtuelle, ainsi qu'une gamme d'autres attributs. Chaque thread exécute le même code de programme et partage la même zone de données et le même tas. Cependant, chaque thread possède sa propre pile contenant des variables locales et des informations de liaison d'appel de fonction. [LPI 2.12]

Ce livre est une source d'une grande clarté; Julia Evans a mentionné son aide pour clarifier le fonctionnement réel des groupes Linux dans cet article .

Exemple 1: une JVM s'exécute dans un seul processus et les threads d'une JVM partagent le segment 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'invocation par un thread d'une méthode et ses variables locales sont conservées à l'abri des autres threads. Mais le tas n'est pas thread-safe et doit être synchronisé pour la sécurité des threads.

Ils sont presque les mêmes ... Mais la principale différence est qu'un thread est léger et qu'un processus est lourd en termes de changement de contexte, de charge de travail, etc.