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

https://stackoverflow.com/questions/200469

03-07-2019
|

Question

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 telles que Erlang ? Existe-t-il une raison définitive d'utiliser un terme plutôt qu'un autre?

La solution

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 ce que le "matériel" vs " logiciel " vous pouvez vous référer à des discussions. Les threads sont une fonctionnalité de l'environnement d'exploitation plutôt qu'une fonctionnalité du processeur (bien que le processeur comporte 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 la mémoire partagée.

Autres conseils

Processus
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é dans 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'exceptions, une priorité de planification, un stockage local du thread, un identifiant 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 de 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 mode 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 que de processeurs sur l'ordinateur.

Processus:

Une instance d'exécution d'un programme s'appelle 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ée mémoire principale ou mémoire à accès aléatoire.
Par conséquent, un processus est appelé 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 à un seul processeur, bien que le parallélisme réel ne soit pas obtenu, 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 de discussion:

Un fil est un sous-ensemble du processus.
Il s’agit d’un "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.
En règle générale, un processus ne comporte qu'un seul thread de contrôle: un ensemble d'instructions machine à exécuter à la fois.
Un processus peut également être composé de plusieurs threads d'exécution qui exécutent les instructions simultanément.
Plusieurs threads de contrôle peuvent exploiter le vrai parallélisme possible sur les systèmes multiprocesseurs.
Sur un système à un seul processeur, un algorithme de planification de thread est appliqué et le processeur est planifié pour exécuter chaque thread à la fois.
Tous les threads s'exécutant dans un processus partagent le même espace adresse, les mêmes descripteurs de fichier, la même pile et d'autres attributs liés au processus.
Etant 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 prend une importance sans précédent.

J'ai emprunté les informations ci-dessus au Quête de connaissance! blog .

Tout d’abord, examinons 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.

Nous avons les éléments suivants de la section 2.2.2 Le modèle de fil classique dans Systèmes d'exploitation modernes 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 discussions entrent en jeu ....

Il continue:

Une façon de voir un processus est qu’il s’agit d’un moyen 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 fil d'exécution, généralement raccourci pour simplement enfiler. Le fil a un compteur de programme qui garde trace de la suivante instruction à exécuter. 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 le fil et son processus sont des concepts différents et peuvent être traités separe. Les processus sont utilisés pour regrouper des ressources; les fils sont les entités dont l'exécution est programmé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        |

Traitons le problème de multithreading matériel . Classiquement, une CPU prend en charge un seul thread d'exécution, conservant 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 une cache manquante? Il faut beaucoup de temps pour extraire des 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 sur 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 manières.

Threads de l'espace utilisateur
Threads du noyau
Une combinaison des deux

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 du programme dans de nombreux cas.

Les threads du noyau ont l’avantage de pouvoir utiliser des E / S bloquantes, 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 thread à cause d’une E / S bloquée, 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.

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 de poids léger", je ne vois pas personnellement l'intérêt de ce terme car il ne dit pas vraiment ce qui se passe ainsi que le terme "thread 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.
Des 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 le 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 faisaient 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é dans ici .

Un processus est un ensemble de codes, 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.

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

Exemple concret pour Process and Thread Ceci 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:

Le processus est lourd.
Le processus est un programme séparé qui possède une mémoire, des données et des ressources distinctes, etc.
Les processus sont créés à l'aide de la méthode fork ().
Le changement de contexte entre le processus prend beaucoup de temps.

Exemple:
Dites, ouvrez n’importe quel navigateur (Mozilla, Chrome, IE). À ce stade, un nouveau processus va commencer à s'exécuter.

Discussions:

Les threads sont des processus légers. Les threads sont regroupés dans le processus.
Les threads ont une mémoire partagée, des données, des ressources, des fichiers, etc.
Les threads sont créés à l'aide de la méthode clone ().
Les changements de contexte entre les threads ne prennent pas beaucoup de temps en tant que processus.

Exemple:
Ouverture de plusieurs onglets dans le navigateur.

Les deux threads et processus sont 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 CPU 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:

Ressources partagées (les threads partagent par définition la mémoire, ils ne possèdent rien sauf des variables de pile et locales; les processus peuvent également partager de la mémoire, mais il existe un mécanisme séparé pour cela, géré par le système d'exploitation)
Espace d'allocation (espace du noyau pour les processus par rapport à l'espace utilisateur pour les threads)

Greg Hewgill a indiqué correctement la signification du mot "processus" en Erlang et ici , il existe une discussion sur les raisons pour lesquelles Erlang pourrait utiliser des processus légers.

Processus

Est un programme en exécution. il contient la section de texte, c’est-à-dire le code du programme, l’activité en cours, représentée par la valeur du compteur de programme & amp; 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 les variables globales. Un processus peut également inclure un segment de mémoire, c’est-à-dire une mémoire allouée dynamiquement pendant son exécution.

Fil de discussion

Un thread est une unité d'utilisation de base 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

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 au sein du processus. Un processus peut contenir plusieurs threads. Un thread est parfois appelé processus 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 capable de dessiner en lisant les frappes. 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 threads nous permettent de faire cela. Ici, dessiner une image est un processus et lire une frappe 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 dans un processus. En outre, un processus peut contenir plusieurs threads. Il est important de noter qu’un thread peut faire tout ce que peut faire un processus. Mais comme un processus peut comprendre plusieurs threads, un thread peut être considéré comme un & # 8216; léger & # 8217; processus. 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 plus de & # 8216; poids lourds & # 8217; tâches & # 8211; 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 à 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. Communication entre processus & # 8211; également connu sous le nom de IPC, ou communication inter-processus & # 8211; est assez difficile et consomme 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écessite pas d'espace d'adressage séparé.
Le multithreading nécessite une programmation minutieuse car les threads partage des structures de données qui ne devraient être modifiées que par un seul thread à la fois. Contrairement aux threads, les processus ne partagent pas le même espace adresse.
Les threads sont considérés comme légers car ils utilisent beaucoup moins de ressources que de processus.
Les processus sont indépendants les uns des autres. Les fils, puisqu'ils les mêmes espaces d'adresses sont interdépendants, donc prudence doit être pris pour que les différents fils ne se chevauchent pas.
C’est vraiment une autre façon de dire # 2 ci-dessus.
Un processus peut comprendre plusieurs threads.

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] [fil] [sujet] [auteur]

Message suivant: Bernd P. Ziller: "Re: Oops in get_hash_table"

Message précédent: Linus Torvalds: "Re: Commande de demandes d’E / S"

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


Nous devons garder le concept de threads clair. 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 un     essayez de rester à une discussion de haut niveau.


NON!

Il n'y a AUCUNE raison de penser que les "discussions" et " traite " sont   entités séparées. C'est comme ça que ça se fait traditionnellement, mais je   pense personnellement que c'est une grave erreur de penser de cette façon. Le seul   raison de penser de cette façon est un bagage historique.

Les threads et les processus ne sont en réalité qu’une chose: un "contexte de"   exécution ". Essayer de distinguer artificiellement différents cas n’est que   auto-limitation.

Un "contexte d'exécution", appelé ici COE, n'est que le conglomérat   de tout l'état de ce COE. Cet état inclut des choses comme le processeur   état (registres, etc.), état MMU (mappages de pages), état d'autorisation   (uid, gid) et divers "états de communication" (fichiers ouverts, signal   gestionnaires etc.). Traditionnellement, la différence entre un " thread " et un   " traiter " a été principalement qu'un thread a l'état de la CPU (+ éventuellement   autre état minimal), alors que tout l’autre contexte provient de la   processus. Cependant, c'est juste   Une une manière de diviser l’état total du centre d’expérience, et rien ne dit que c’est la bonne façon de le faire. Vous limiter   à ce genre d'image est tout simplement stupide.

La façon dont Linux pense cela (et la façon dont je veux que les choses fonctionnent) est   qu’il n’existe pas de processus ou un "fil". Il y a   seule la totalité du COE (appelée "tâche" par Linux). Différents COE   peuvent partager certaines parties de leur contexte et un sous-ensemble de   ce partage est le processus traditionnel "thread" / "processus". configuration, mais ça   devrait vraiment être considéré comme un SEUL sous-ensemble (c’est un sous-ensemble important, mais   cette importance ne vient pas de la conception, mais des normes: nous obviusly   voulez 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   le noyau devrait être conçu autour de la pensée du COE, puis le   pthreads bibliothèque peut exporter l'interface limitée de pthreads aux utilisateurs   qui veulent utiliser cette façon de voir les COE.

Juste à titre d'exemple de ce qui devient possible lorsque vous pensez que COE est   opposé à thread / processus:


Vous pouvez créer un "cd" externe. programme, quelque chose qui est traditionnellement impossible sous UNIX et / ou processus / thread (exemple stupide, mais l'idée   est-ce que vous pouvez avoir ce genre de " modules " qui ne sont pas limités à   la configuration UNIX / threads traditionnelle). Faites un:


clone (CLONE_VM | CLONE_FS);

child: execve ("external-cd");

/ * the "execve ()" va dissocier la VM, donc la seule raison pour laquelle nous   CLONE_VM utilisé devait accélérer le processus de clonage * /


Vous pouvez faire "vfork () " naturellement (cela signifie un support minimal du noyau, mais ce support correspond parfaitement à la façon de penser de la CUA):


clone (CLONE_VM);

child: continuer à courir, éventuellement execve ()

mère: attendez l'exécutif


vous pouvez créer des "démons IO" externes:


clone (CLONE_FILES);

enfant: ouvrir les descripteurs de fichier, etc.

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

Tout ce qui précède fonctionne parce que vous n'êtes pas lié au fil / processus   façon de penser. Pensez à un serveur Web par exemple, où le CGI   Les scripts sont réalisés sous la forme de "threads d'exécution". Vous ne pouvez pas faire ça avec   fils traditionnels, car les fils traditionnels doivent toujours être partagés   tout l'espace d'adressage, vous devrez donc créer un lien dans tout ce que vous avez déjà   voulait faire dans le serveur Web lui-même (un "thread" ne peut pas exécuter un autre   exécutable).

En pensant à cela comme un "contexte d'exécution" problème à la place, votre   les tâches peuvent maintenant choisir d’exécuter des programmes externes (= séparer le   espace d'adressage du parent) etc. s'ils le souhaitent, ou peuvent le faire   exemple tout partager avec le parent sauf pour le fichier   descripteurs (afin que les sous-threads puissent ouvrir beaucoup de fichiers sans   le parent ayant besoin de s’inquiéter pour eux: ils se ferment automatiquement quand   le sous-"fil" " exits, et il n’utilise pas fd dans le parent).

Pensez à un "inetd" fileté, par exemple. Vous voulez des frais généraux bas   fork + exec, vous pouvez donc utiliser la méthode "fork ()" au lieu de Linux.   vous écrivez un inetd multi-thread où chaque thread est créé avec   juste CLONE_VM (partage d'espace d'adressage, mais ne partage pas les descripteurs de fichier)   etc). Ensuite, l’enfant peut exécuter s’il s’agissait d’un service externe (rlogind,   par exemple), ou peut-être était-ce l’un des services internes inetd   (echo, timeofday) auquel cas il fait juste sa chose et sort.

Vous ne pouvez pas le faire avec les "threads" / "processus".

Linus

Du point de vue de l'interviewer, il y a en gros 3 choses que je veux entendre. En plus des choses évidentes comme un processus peut avoir plusieurs fils:

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.
Ressources. Les ressources (mémoire, descripteurs, sockets, etc.) sont libérées à la fin du processus et non à la fin du thread.
Sécurité. Un processus a un jeton de sécurité fixe. En revanche, un thread peut emprunter l'identité de différents utilisateurs / jetons.

Si vous voulez plus, la réponse de Scott Langham couvre presque tout. Tous ces éléments sont 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. Des exceptions et des interruptions matérielles et logicielles ou des threads en mode utilisateur et du noyau .

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

Voici un extrait de l'un des articles du Le projet de code . Je suppose que cela explique clairement tout ce qui est nécessaire.

Un thread est un autre mécanisme permettant de scinder le workload en plusieurs flux d'exécution. Un fil est plus léger qu'un processus. Ce En d'autres termes, il offre moins de flexibilité qu'un processus complet, mais peut être lancé plus rapidement car il y a moins de ressources pour le système d'exploitation installer. Quand un programme se compose de deux ou plusieurs threads, tous les 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.

Fondamentalement, un thread fait partie d'un processus sans que celui-ci ne puisse pas fonctionner.
Un fil est léger alors que le processus est lourd.
la communication entre processus nécessite un peu de temps alors que le thread nécessite moins de temps.
Les threads peuvent partager la même zone mémoire alors que le processus vit séparément.

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

Fil de discussion : le fil de discussion est une fonctionnalité exécutée avec l'autre partie du programme sur la base du concept de "l'un avec l'autre", de sorte que le fil de discussion fait partie du processus.

Venant du monde intégré, je voudrais ajouter que le concept de processus n’existe que dans "gros". les processeurs ( ordinateurs de bureau, ARM Cortex A-9 ) dotés d'un 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'y a pas de support MMU et donc pas de processus, mais uniquement des threads.

Les threads peuvent accéder à la mémoire de chacun. 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 , par contre, résident dans leur sandbox privé de mémoire virtuelle, fourni et gardé par MMU. C'est pratique car cela permet:

empêche les processus anormaux de planter tout le système.
Assurer la sécurité en rendant invisibles les données des processus et inaccessible. Le travail réel dans le processus est pris en charge par un ou plusieurs threads.

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é ¹. Cela signifie que le programme doit être interprété pour pouvoir être exécuté et que l'interpréteur n'est pas au courant du programme avant son exécution. 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 bien compilé. Le programme est traité "entièrement", où il est d'abord interprété conformément à ses définitions syntaxiques, puis mappé à une représentation intermédiaire agnostique en langage, et finalement lié à un code exécutable. Ce processus permet d’optimiser 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 lorsqu’il est possible de prendre des décisions éclairées en matière d’optimisation.

Dans les environnements modernes, l'interpréteur Python doit autoriser 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 de différents threads, tout en optimisant l’utilisation des processeurs pour les calculs.

Comme il a été noté dans les publications précédentes, un processus et un fil 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.

¹ Donald Knuth a une bonne explication des routines d'interprétation dans L'Art de la programmation informatique: algorithmes fondamentaux.

Essayer d'y répondre depuis la vue système d'exploitation 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 que le segment .text pour le stockage du code compilé, le fichier .bss pour le stockage des variables statiques ou globales non initialisées, etc. Chaque processus aura son propre compteur de programme et son propre utilisateur empiler . À 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 tâche_struct qui est généralement abstraite en tant que bloc de contrôle de processus, stockant toutes les informations concernant. le processus tel que sa priorité, son état (et beaucoup d'autres éléments). Un processus peut avoir plusieurs threads d'exécution.

En venant dans les 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 du thread, telles que les ressources du système de fichiers, le partage des signaux en attente, le partage des données (variables et instructions) Les fils sont légers et permettent donc 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 programmables 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 ).

Pour ceux qui préfèrent apprendre 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

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 segment de mémoire. Les threads ne s'exécutant jamais de manière indépendante, la communication entre threads est beaucoup plus rapide que la communication entre 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:

Process 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 à 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 à un seul processeur, 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 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 de discussion:

Un thread est un sous-ensemble du processus. Il s’appelle un «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. En règle générale, un processus ne comporte qu'un seul thread de contrôle, à savoir un ensemble d'instructions machine à exécuter à 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 vrai parallélisme possible sur les systèmes multiprocesseurs. Sur un système mono-processeur, un algorithme de planification de thread est appliqué et le processeur est planifié pour exécuter chaque thread un à la fois. Tous les threads exécutés dans un processus partagent 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 prend une importance sans précédent.

ref- https://practice.geeksforgeeks.org/problems / différence-entre-processus-et-fil

La meilleure réponse que j'ai trouvée à ce jour est L'interface de programmation 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 de créer 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 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 préciser le fonctionnement réel des groupes Linux dans cet article .

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.

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.

Envisagez un processus comme une unité de propriété ou les ressources nécessaires à une tâche. Un processus peut avoir des ressources comme l’espace mémoire, des entrées / sorties spécifiques, des fichiers spécifiques, des priorités, etc.

Un fil de discussion est une unité d’exécution pouvant être acheminée ou, en termes simples, la progression dans une séquence d’instructions

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow