Linux – threads et priorités de planification des processus

Linux ne programme plus du tout les processus.

Dans le kernel, les threads sont planifiés. Le concept d’un processus est maintenant une construction artificielle vue principalement par des éléments extérieurs au kernel. De toute évidence, le kernel doit savoir comment les threads sont liés ensemble, mais pas à des fins de planification.

Fondamentalement, le kernel conserve un grand nombre de threads et chaque thread a un leader de groupe de threads, ce qui est ce que l’on voit à l’extérieur du processus. Un thread a un identifiant de thread et un identifiant de groupe de threads. Il ressemble beaucoup à la relation entre un PID et un PPID (identifiant de processus et identifiant de processus parent).

Lorsque vous créez un thread régulier , le kernel lui atsortingbue un nouvel identifiant de thread, mais son identifiant de groupe de threads est identique à celui du thread qui l’a créé. De cette façon, il ressemble à un fil dans un processus vers le monde extérieur.

Lorsque vous faites un fork, le kernel lui atsortingbue un nouvel identifiant de thread et définit son identifiant de groupe de thread à la même valeur que son identifiant de thread. De cette façon, cela ressemble à un processus vers le monde extérieur.

La plupart des utilitaires autres que le kernel qui signalent des processus ne font que rapporter des threads pour lesquels l’ID de thread est identique à l’ID de groupe de threads.

Il y a des subtilités avec d’autres méthodes qui sont probablement trop compliquées pour entrer ici. Ce que j’ai écrit ci-dessus est (espérons-le) un bon traité de niveau moyen.

Maintenant, pour votre question spécifique, ce ne serait pas le cas puisque P1 n’a qu’un seul thread (il n’y a pas de P1T2 ).

Avec le kernel, les threads sont P1T1 , P2T1 et P2T2 et, en supposant qu’ils ont les mêmes propriétés de planification et se comportent de la même manière ^(a) , c’est comme ça qu’ils seront programmés.

Voir également:

• Linux – Threads et processus ;
• Si j’ai un processus et que je le clone, le PID est-il le même? ; et
• Un processus CPU aura-t-il au moins un thread?

pour plus d’informations.

^(a) : Évidemment, cela change si les threads commencent à se bloquer sur les E / S (le kernel ne les planifie pas avant que les E / S ne soient disponibles) ou libère leurs quanta de temps plus tôt mais alors ils ne se comportent pas de la même façon.

Il est vrai que le kernel Linux (à partir de la version 2.6.23 et suivantes) planifie les tâches, qui sont soit des threads, soit des processus (mono-thread).

En plus de la réponse acceptée de paxdiablo, j’ajoute celle-ci afin d’append une autre vue informative générique sur les différentes méthodes de planification des threads.

En général, les threads peuvent être des threads d’espace utilisateur ou des threads d’espace kernel . Les threads de l’espace utilisateur sont généralement implémentés par une bibliothèque. Ainsi, le kernel ne sait presque rien à leur sujet (le kernel ne connaît que le processus auquel ils appartiennent) et ils sont gérés dans l’espace utilisateur. Au contraire, les threads du kernel sont implémentés par le kernel et ils sont entièrement gérés par le kernel. Vous pouvez prendre une vue générique à partir de l’image suivante.

Comme vous pouvez le voir, l’image de gauche montre certains threads de l’espace utilisateur, où le kernel ne possède que des informations sur les processus (appelés blocs de contrôle de processus – PCB ). Toutes les ressources-info concernant les threads sont conservées à l’intérieur du processus (dans une table de threads) et gérées par la bibliothèque de threads correspondante dans l’espace utilisateur. Dans la bonne image, vous pouvez voir les threads du kernel, où la table des processus et la table des threads sont conservées dans le kernel.

Un exemple de threads du kernel sont LinuxThreads , qui ont maintenant été remplacés par la bibliothèque NPTL plus moderne. Un exemple de threads d’espace utilisateur est la bibliothèque GNU Portable Threads

Maintenant, en ce qui concerne la planification, comme prévu, les threads d’espace utilisateur sont planifiés différemment des threads du kernel:

• Lorsque des threads d’espace utilisateur sont utilisés, le planificateur planifie les processus. Ainsi, il sélectionne un processus spécifique et alloue le quantum de temps autorisé. Ensuite, le programmateur de threads à l’intérieur du processus est chargé de sélectionner la manière dont la planification entre les threads sera effectuée. Comme les threads de l’espace utilisateur ne sont pas arrêtés par des interruptions, le thread sélectionné aura tendance à consumr tout le quantum du processus jusqu’à ce qu’il ait terminé sa tâche. Donc, la programmation hypothétique dans ce cas serait quelque chose comme:

  P1 (T1), P2 (T1), P1 (T1), P2 (T1 – T1 termine sa tâche et cède ), P2 (T2 – pour le quantum de temps restant, P1 (T1), P2 (T2), P1 (T1) ), …

• Lorsque les threads du kernel sont utilisés, le kernel planifie les threads. Le kernel ne montre aucun intérêt pour le processus auquel le thread appartient, mais il alloue un quantum de temps à chaque thread de manière égale. Donc, dans ce cas, la programmation hypothétique serait:

  P1 (T1), P2 (T1), P2 (T2), P1 (T1), P2 (T2), P1 (T1), …

Notez qu’il existe également une autre catégorie, les threads hybrides , où certains threads d’espace utilisateur sont traduits dans un thread de kernel. Cependant, il est plus complexe et nécessite une parsing plus approfondie.