Voir: Comprendre le noyau Linux , 3e édition par Daniel P. Bovet, Marco Cesati
- Éditeur: O'Reilly
- Date de publication: novembre 2005
- ISBN: 0-596-00565-2
- Pages: 942
Dans leur introduction, Daniel P. Bovet et Marco Cesati ont déclaré:
Techniquement parlant, Linux est un véritable noyau Unix, bien qu'il ne soit pas un système d'exploitation complet Unix, car il n'inclut pas toutes les applications telles que les utilitaires de système de fichiers, les systèmes de fenêtrage et les bureaux graphiques, les commandes de l'administrateur système, les éditeurs de texte, les compilateurs, etc. sur. Par conséquent, ce que vous lisez dans ce livre et voyez dans le noyau Linux peut vous aider à comprendre les autres variantes d'Unix.
Dans les paragraphes suivants, j'essaierai d'adresser vos points de vue en fonction de ma compréhension des faits présentés dans "Comprendre le noyau Linux" qui sont dans une large mesure similaires à ceux d'Unix.
Qu'est-ce qu'un processus signifie? :
Les processus sont comme des êtres humains, ils sont générés, ils ont une vie plus ou moins importante, ils génèrent éventuellement un ou plusieurs processus enfants, et finalement ils meurent. Un processus comprend cinq parties fondamentales: code ("texte"), données (VM), pile, E / S de fichiers et tables de signaux
Le but d'un processus dans le noyau est d'agir comme une entité à laquelle les ressources système (temps CPU, mémoire, etc.) sont allouées. Lorsqu'un processus est créé, il est presque identique à son parent. Il reçoit une copie (logique) de l'espace d'adressage du parent et exécute le même code que le parent, en commençant à la prochaine instruction suivant l'appel système de création de processus. Bien que le parent et l'enfant puissent partager les pages contenant le code du programme (texte), ils ont des copies distinctes des données (pile et tas), de sorte que les modifications apportées par l'enfant à un emplacement de mémoire sont invisibles pour le parent (et vice versa) .
Comment fonctionnent les processus?
Un programme en cours d'exécution a besoin de plus que du code binaire qui indique à l'ordinateur quoi faire. Le programme a besoin de mémoire et de diverses ressources du système d'exploitation pour fonctionner. Un «processus» est ce que nous appelons un programme qui a été chargé en mémoire avec toutes les ressources dont il a besoin pour fonctionner. Un thread est l'unité d'exécution d'un processus. Un processus peut avoir entre un seul thread et plusieurs threads. Lorsqu'un processus démarre, une mémoire et des ressources lui sont attribuées. Chaque thread du processus partage cette mémoire et ces ressources. Dans les processus à thread unique, le processus contient un thread. Le processus et le fil sont une seule et même chose, et il ne se passe qu'une seule chose. Dans les processus multithreads, le processus contient plusieurs threads et le processus accomplit un certain nombre de choses en même temps.
La mécanique d'un système multi-traitement comprend des processus légers et lourds:
Dans un processus lourd, plusieurs processus s'exécutent ensemble en parallèle. Chaque processus lourd en parallèle a son propre espace d'adressage mémoire. La communication inter-processus est lente car les processus ont des adresses mémoire différentes. La commutation de contexte entre les processus est plus coûteuse. Les processus ne partagent pas la mémoire avec d'autres processus. La communication entre ces processus impliquerait des mécanismes de communication supplémentaires tels que des prises ou des tuyaux.
Dans un processus léger, également appelé threads. Les threads sont utilisés pour partager et diviser la charge de travail. Les threads utilisent la mémoire du processus auquel ils appartiennent. La communication inter-threads peut être plus rapide que la communication inter-processus car les threads du même processus partagent la mémoire avec le processus auquel ils appartiennent. en conséquence, la communication entre les threads est très simple et efficace. La commutation de contexte entre les threads du même processus est moins coûteuse. Les threads partagent la mémoire avec d'autres threads du même processus
Il existe deux types de threads: les threads de niveau utilisateur et les threads de niveau noyau. Les threads au niveau utilisateur évitent le noyau et gèrent le travail de manière autonome. Les threads de niveau utilisateur ont un problème qu'un seul thread peut monopoliser la tranche de temps, affaiblissant ainsi les autres threads de la tâche. Les threads de niveau utilisateur sont généralement pris en charge au-dessus du noyau dans l'espace utilisateur et sont gérés sans prise en charge du noyau. Le noyau ne sait rien des threads de niveau utilisateur et les gère comme s'il s'agissait de processus à thread unique. En tant que tel, les threads au niveau utilisateur sont très rapides, il fonctionne 100 fois plus rapidement que les threads du noyau.
Les threads au niveau du noyau sont souvent implémentés dans le noyau à l'aide de plusieurs tâches. Dans ce cas, le noyau planifie chaque thread dans la tranche de temps de chaque processus. Ici, étant donné que l'horloge détermine les heures de commutation, une tâche est moins susceptible de monopoliser la tranche de temps des autres threads de la tâche.Les threads de niveau noyau sont pris en charge et gérés directement par le système d'exploitation. La relation entre les threads au niveau utilisateur et les threads au niveau du noyau n'est pas complètement indépendante, en fait il y a une interaction entre ces deux niveaux. En général, les unités d'exécution au niveau de l'utilisateur peuvent être implémentées à l'aide de l'un des quatre modèles: modèles plusieurs-à-un, un-à-un, plusieurs-à-plusieurs et à deux niveaux. Tous ces modèles mappent les threads de niveau utilisateur aux threads de niveau noyau et provoquent une interaction à différents degrés entre les deux niveaux.
Threads vs processus
- Le programme démarre comme un fichier texte de code de programmation,
- Le programme est compilé ou interprété sous forme binaire,
- Le programme est chargé en mémoire,
- Le programme devient un ou plusieurs processus en cours d'exécution.
- Les processus sont généralement indépendants les uns des autres,
- Alors que les threads existent en tant que sous-ensemble d'un processus.
- Les threads peuvent communiquer entre eux plus facilement que les processus,
- Mais les threads sont plus vulnérables aux problèmes causés par d'autres threads dans le même processus
Les références:
Comprendre le noyau Linux, 3e édition
Plus 1 2 3 4 5
...............................................
Maintenant, simplifions tous ces termes ( ce paragraphe est de mon point de vue ). Le noyau est une interface entre le logiciel et le matériel. En d'autres termes, le noyau agit comme un cerveau. Il manipule une relation entre le matériel génétique (c'est-à-dire les codes et ses logiciels dérivés) et les systèmes du corps (c'est-à-dire le matériel ou les muscles).
Ce cerveau (c'est-à-dire le noyau) envoie des signaux aux processus qui agissent en conséquence. Certains de ces processus sont comme des muscles (c.-à-d. Des fils), chaque muscle a sa propre fonction et tâche, mais ils travaillent tous ensemble pour terminer la charge de travail. La communication entre ces fils (c'est-à-dire les muscles) est très efficace et simple, de sorte qu'ils accomplissent leur travail en douceur, rapidement et efficacement. Certains fils (c'est-à-dire les muscles) sont sous le contrôle de l'utilisateur (comme les muscles de nos mains et de nos jambes). D'autres sont sous le contrôle du cerveau (comme les muscles de l'estomac, des yeux, du cœur que nous ne contrôlons pas).
Les threads de l'espace utilisateur évitent le noyau et gèrent les tâches elles-mêmes. Souvent, ceci est appelé "multitâche coopératif", et en fait, c'est comme nos membres supérieurs et inférieurs, il est sous notre propre contrôle et il travaille tous ensemble pour réaliser le travail (c'est-à-dire des exercices ou ...) et n'a pas besoin d'ordres directs de le cerveau. De l'autre côté, les threads Kernel-Space sont complètement contrôlés par le noyau et son ordonnanceur.
...............................................
En réponse à vos questions:
Un processus est-il toujours mis en œuvre sur la base d'un ou plusieurs processus légers? La figure 3.4 semble dire oui. Pourquoi la figure 3.5 (a) montre-t-elle les processus directement sur les processeurs?
Oui, il existe des processus légers appelés threads et des processus lourds.
Un processus lourd (vous pouvez l'appeler processus de fil de signal) nécessite que le processeur lui-même fasse plus de travail pour ordonner son exécution, c'est pourquoi la figure 3.5 (a) montre les processus directement au-dessus des CPU.
Un processus léger est-il toujours implémenté sur la base d'un thread noyau? La figure 3.4 semble dire oui. Pourquoi la figure 3.5 (b) montre-t-elle des processus légers directement au-dessus des processus?
Non, les processus légers sont divisés en deux catégories: les processus au niveau utilisateur et au niveau du noyau, comme mentionné ci-dessus. Le processus de niveau utilisateur s'appuie sur sa propre bibliothèque pour traiter ses tâches. Le noyau lui-même planifie le processus au niveau du noyau. Les threads au niveau utilisateur peuvent être implémentés à l'aide de l'un des quatre modèles: plusieurs à un, un à un, plusieurs à plusieurs et deux niveaux. Tous, ces modèles mappent les threads de niveau utilisateur aux threads de niveau noyau.
Les threads du noyau sont-ils les seules entités pouvant être planifiées?
Non, les threads au niveau du noyau sont créés par le noyau lui-même. Ils sont différents des threads de niveau utilisateur dans le fait que les threads de niveau noyau n'ont pas d'espace d'adressage limité. Ils vivent uniquement dans l'espace du noyau, sans jamais basculer dans le domaine de la terre des utilisateurs. Cependant, ce sont des entités entièrement programmables et préemptives, tout comme les processus normaux (remarque: il est possible de désactiver presque toutes les interruptions pour les actions importantes du noyau). Le but des propres threads du noyau est principalement d'effectuer des tâches de maintenance sur le système. Seul le noyau peut démarrer ou arrêter un thread du noyau. De l'autre côté, le processus de niveau utilisateur peut se planifier en fonction de sa propre bibliothèque et en même temps, il peut être planifié par le noyau sur la base des modèles à deux niveaux et plusieurs à plusieurs (mentionnés ci-dessus),
Les processus légers ne sont-ils planifiés qu'indirectement via la planification des threads sous-jacents du noyau?
Les threads du noyau sont contrôlés par le planificateur du noyau lui-même. La prise en charge des threads au niveau utilisateur signifie qu'il existe une bibliothèque de niveau utilisateur qui est liée à l'application et cette bibliothèque (et non l'UC) fournit toute la gestion de la prise en charge d'exécution des threads. Il prendra en charge les structures de données qui sont nécessaires pour implémenter l'abstraction des threads et fournira toutes les synchronisations de planification et autres mécanismes nécessaires pour prendre la décision de gestion des ressources pour ces threads. Désormais, certains des processus de threads au niveau utilisateur peuvent être mappés dans les threads sous-jacents au niveau du noyau, ce qui inclut le mappage un à un, un à plusieurs et plusieurs à plusieurs.
Les processus ne sont-ils planifiés qu'indirectement via la planification des processus légers sous-jacents?
Cela dépend s'il s'agit d'un processus lourd ou léger. Les processus lourds sont planifiés par le noyau lui-même. le processus léger peut être géré au niveau du noyau et au niveau de l'utilisateur.
