Oui, j'ai lu beaucoup de matériaux liés à l'exploitation du système. Et je suis toujours à la lecture. Mais il semble tout d'entre eux sont en décrivant le processus et thread dans un "résumé", ce qui rend beaucoup de haut niveau elabration sur leur comportement et logique de la orgnization. Je me demande quels sont-ils physiquement? À mon avis, ils sont juste quelques-uns en mémoire "structures de données" qui sont gérés et utilisés par le noyau des codes pour faciliter l'exécution du programme. Par exemple, le système d'exploitation l'utilisation de certains processus, structure de données (PCB) pour décrire les aspects du processus d'attribution de certains programmes, tels que sa priorité, son espace d'adressage, et ainsi de suite. Est-ce vrai? Désolé si ma question est trop naïf parce que je suis un newbie. Toute réponse serait grandement apprécié... :D
Réponses
Trop de publicités?
La première chose que vous devez savoir pour comprendre la différence entre un processus et un thread, c'est un fait, que le processus ne s'exécute pas, les threads ne.
Alors, qu'est ce qu'un thread? Plus proche que je peux obtenir de l'expliquer c'est un état de l'exécution, comme dans: une combinaison de registres du CPU, de la pile, le lot. Vous pouvez voir une preuve de ce que, par la rupture d'un débogueur à tout moment donné. Que voyez-vous? Une pile d'appel, un ensemble de registres. C'est assez bien. C'est le fil.
Maintenant, alors, ce qui est un processus. Eh bien, c'est comme un résumé "conteneur" de l'entité pour les threads en cours d'exécution. Aussi loin que l'OS est concerné dans une première approximation, c'est une entité OS alloue la VM, attribue des ressources système (comme les descripteurs de fichiers, sockets réseau), &c.
Comment travaillent-ils ensemble? Le système d'exploitation crée un "processus" en réservant certaines ressources, et le démarrage d'une "main" de thread. Ce thread peut alors générer davantage de threads. Ceux sont les threads d'un même processus. Ils ont plus ou de moins peuvent partager ces ressources d'une manière ou d'une autre (par exemple, le verrouillage peut être nécessaire pour eux de ne pas gâcher le plaisir pour d'autres, &c). A partir de là, le système d'exploitation est normalement responsable de l'entretien de ces threads "à l'intérieur" que VM (détecter et de prévenir les tentatives d'accès à la mémoire qui n'est pas "appartenir" à ce processus), la fourniture d'une planification de ces fils, pour qu'ils puissent exécuter "l'un après l'autre-et-pas-juste-un-tout-le-temps".
Normalement, lorsque vous exécutez un fichier exécutable comme notepad.exe cela crée un processus unique. Ces processus pourraient invoquer d'autres processus, mais dans la plupart des cas, il existe un processus unique pour chaque fichier exécutable que vous exécutez. Dans le processus, il peut y avoir plusieurs threads. Habituellement au début, il y a un thread, qui commence généralement à des programmes de "point d'entrée" qui est l' main fonction habituellement. Les Instructions sont exécutées une par une dans l'ordre, comme une personne qui ne dispose que d'une main, un thread ne peut faire qu'une chose à la fois avant de passer à la suivante.
Que le premier thread peut créer des threads supplémentaires. Chaque thread a son propre point d'entrée, ce qui est généralement définie par une fonction. Le processus est comme un conteneur pour tous les threads qui ont vu le jour en son sein.
C'est une jolie explication simpliste. Je pourrais aller plus en détail, mais sans doute ne ferait pas double emploi avec ce que vous trouverez dans vos manuels scolaires.
EDIT: Vous remarquerez que il y a beaucoup de "habituellement"'s dans mon explication, car il y a parfois des rares programmes qui font des choses radicalement différentes.
L'une des raisons pour lesquelles il est quasiment impossible à décrire les threads et les processus dans un non-abstraite, c'est qu'ils sont des abstractions.
Leur des implémentations concrètes diffèrent énormément.
Comparer par exemple un Erlang Processus et un Processus de Windows: un Processus Erlang est très léger, souvent à moins de 400 Octets. Vous pouvez commencer à 10 millions de processus sur un ordinateur portable récent sans aucun problème. Ils commencent très rapidement, ils meurent très rapidement et vous êtes censé être en mesure de les utiliser pour de très courtes tâches. Chaque Erlang Processus a son propre Garbage Collector associés. Processus Erlang ne peut jamais partager de la mémoire, à jamais.
Les Processus Windows sont très lourdes, parfois des centaines de MiBytes. Vous pouvez commencer peut-être un couple de milliers d'entre eux sur un costaud serveur, si vous avez de la chance. Ils commencent à mourir assez lentement. Des Processus Windows sont les unités d'Applications telles que des IDEs ou des Éditeurs de Texte ou traitement de texte, de sorte qu'ils sont généralement attendre à vivre un temps assez long (plusieurs minutes). Ils ont leur propre Espace d'adressage, mais pas de Garbage Collector. Windows les Processus peuvent partager de la mémoire, bien que par défaut, ils ne le font pas.
Les fils sont de la même façon: un NPTL Linux Threads sur les processeurs x86 peut être que 4 KiByte et avec quelques astuces, vous pouvez commencer à 800000+ sur un 32 Bits x86 machine. La machine sera certainement utilisable avec des milliers, peut-être des dizaines de milliers de threads. Un .NET CLR Thread a une taille minimale d'environ 1 MiByte, ce qui signifie que seulement 4000 de ceux qui vont manger l'intégralité de votre espace d'adressage sur un ordinateur 32 Bits. Ainsi, alors que 4000 NPTL Linux Threads est généralement pas un problème, vous ne pouvez même pas commencer à 4000 .NET CLR Fils parce que vous serez à court de mémoire avant que.
OS des Processus et des Threads OS sont également mis en œuvre de manière très différente entre les différents Systèmes d'Exploitation. Les deux principales approches sont: le noyau sait seulement sur les processus. Les fils sont mis en œuvre par un Utilisateur de la Bibliothèque, sans aucune connaissance du noyau à tous. Dans ce cas, il existe deux approches: 1:1 (chaque Fil correspond à un Noyau de Processus) ou m:n (m Fils de la carte de Processus n, où m > n et souvent n == #CPUs). Ce fut le début de l'approche adoptée sur de nombreux Systèmes d'Exploitation après les Threads ont été inventés. Toutefois, il est généralement jugées inefficaces et a été remplacé sur presque tous les systèmes par la deuxième approche: les Fils sont mis en œuvre (au moins partiellement) dans le noyau, de sorte que le noyau connaît désormais deux entités distinctes, les Threads et les Processus.
Un Système d'Exploitation qui va une troisième voie, est Linux. Sous Linux, les Threads ne sont ni mis en œuvre dans l'espace Utilisateur, ni dans le Noyau. Au lieu de cela, le Noyau fournit une abstraction de la fois d'un Fil et d'un Processus (et même un couple de plus de choses), a appelé à une Tâche. Une Tâche est un Noyau Prévue Entité, qui porte avec elle un ensemble d'indicateurs qui déterminent les ressources qu'il partage avec ses frères et sœurs et ceux qui en sont privés.
Selon la façon dont vous définissez ces options, vous obtenez soit un Thread (partager à peu près tout) ou d'un Procédé (partage de toutes les ressources du système, comme le système de l'horloge, le système de fichiers de l'espace de noms, la mise en réseau de l'espace de noms, l'ID utilisateur de l'espace de noms, le processus d'ID d'espace de noms, mais ne pas partager l'Espace d'adressage). Mais vous pouvez également obtenir d'autres jolies choses intéressantes, trop. Vous pouvez trivialement obtenir BSD-style prisons (essentiellement les mêmes drapeaux comme un Processus, mais ils ne partagent pas le système de fichiers ou la mise en réseau de l'espace de noms). Ou vous pouvez obtenir ce que d'autres systèmes d'exploitation appeler une Virtualisation du Conteneur ou de la Zone (comme une prison, mais ils ne partagent pas l'UID et le PID espaces de noms et de l'horloge système). Depuis une couple d'années, par l'intermédiaire d'une technologie appelée KVM (Kernel Virtual Machine), vous pouvez même obtenir une pleine soufflé à la Machine Virtuelle (part de rien, pas même le processeur de Tables de Page). [La chose cool à propos de cette est que vous obtenez de la réutilisation de la très à l'écoute mature Planificateur de Tâches dans le noyau de toutes ces choses. Une des choses que la Machine Virtuelle Xen a souvent critiqué pour, a été la mauvaise performance de son programmateur. Le KVM les développeurs ont beaucoup supérieure planificateur de Xen, et la meilleure chose est qu'ils n'ont même pas avoir à écrire une seule ligne de code!]
Donc, sur Linux, la performance de Threads et de Processus est beaucoup plus proche que celle de Windows et de nombreux autres systèmes, car sous Linux, ils sont en fait la même chose. Ce qui signifie que les modèles d'utilisation sont très différents: sur Windows, vous décider entre l'utilisation d'un Fil et d'un Processus en fonction de leur poids: puis-je me permettre un Processus ou dois-je utiliser un Thread, même si en fait je ne veux pas partager l'état? Sur Linux (et Unix en général), vous décider en fonction de leur sémantique: ai-je réellement envie de partager l'état ou pas?
L'une des raisons pourquoi les Processus ont tendance à être plus léger sur Unix que sous Windows, ce qui est différent d'utilisation: sur Unix, les Processus sont l'unité de base à la fois de la simultanéité et de la fonctionnalité. Si vous souhaitez utiliser la simultanéité, l'utilisation de plusieurs Processus. Si votre application peut être décomposé en plusieurs entités indépendantes de l'utilisation de plusieurs Processus. Chaque Processus fait exactement une chose et seulement une seule chose. Même une simple ligne de script shell implique souvent des dizaines ou des centaines de Processus. Les Applications se composent généralement de nombreux, souvent, des Processus à court terme.
Sur Windows, les Threads sont les unités de base de la concurrence et les composants COM ou .NET les objets sont les unités de base de la fonctionnalité. Les Applications sont généralement constituées d'un seul long Processus en cours d'exécution.
Encore une fois, ils sont utilisés pour des fins très différentes et sont très différentes des objectifs de conception. Ce n'est pas que l'un ou l'autre est meilleur ou pour le pire, c'est juste qu'ils sont tellement différents que les caractéristiques communes qui ne peut être décrit de façon très abstraite.
À peu près la seule quelques choses que vous pouvez dire à propos de Threads et de Processus sont les suivantes:
- Fils appartiennent à des Processus de
- Les Threads sont plus légers que les Processus de
- Les Threads partagent la plupart de l'état les uns avec les autres
- Processus partagent beaucoup moins de l'état de Threads (en particulier, ils partagent généralement pas de mémoire, sauf demande spécifique)
