Processus de thread sous Linux

Je m'interroge sur la "punition" qui se produit lorsqu'un nouveau fil est créé.

D'après ma compréhension de clone (2), NPTL (nouvelle bibliothèque de threads POSIX) et CFS (planificateur parfaitement équitable), lorsqu'un nouveau thread est créé, il est considéré comme un nouveau processus car NPTL utilise un modèle de thread 1: 1.

D'après ce que j'ai lu sur le planificateur, lorsqu'un nouveau processus est ajouté à la file d'attente d'exécution, la fair_clockvariable augmente jusqu'à une fraction de l'horloge murale.

En parcourant les rituels avec pthread_create (3), le clone est appelé comme il le ferait dans un fork (2).

Maintenant, un processus aura un modèle 1: 1 et donc les threads. Ainsi, un fil subit-il également le même sort ? De toute évidence, un thread doit être puni sous une forme quelconque, sinon un processus à plusieurs threads peut accaparer la plus grande partie du temps CPU en remplissant le système RR (round robin) utilisé par CFS.

Si cela est vrai, quels sont les avantages d'utiliser des threads sur des fourches? S'agit-il uniquement de l'espace de partage partagé automatique (par opposition à l'utilisation de shm_open (2))?

linux scheduling thread

— SailorCire
source

La documentation à laquelle vous vous connectez ne décrit pas le SCF (le livre date de ~ 2000; le SCF a été introduit en 2007), indiquant que "réduire de moitié le laps de temps" ne se produit pas directement avec le SCF - il n’a pas les tranches de temps traditionnelles.

— Mat

Oh, et "juste l'espace <strike> d'espace disque partagé </ strike> partagé" n'est pas un détail, c'est un modèle complètement différent de processus distincts et nécessite des techniques de programmation très différentes.

— Mat

@Mat Vous avez raison, même la 3e édition, qui couvre la version 2.6, a été protégée par le droit d'auteur en 2006 et par core.c mentionne le 2007-04-15. En espérant qu'un quatrième sortira bientôt. Je vais lire une partie du code et essayer de modifier le post.

— SailorCire

@Mat a édité pour CFS maintenant et a créé un lien vers un article de LJ.

— SailorCire

Correct, la raison d'utiliser un thread plutôt qu'un processus séparé est lorsque vous souhaitez un espace d'adressage partagé.

— Simon Richter

D'après le lien que j'ai fourni à propos de l'ordonnanceur complètement équitable, nous voyons que dans le noyau 2.6.24 se trouve ce qu'on appelle l'ordonnancement de groupe.

Pour citer Chandandeep Singh Pabla:

Par exemple, supposons qu'il y ait au total 25 processus exécutables dans le système. CFS essaie d'être juste en allouant 4% de la CPU à tous. Toutefois, supposons que sur ces 25 processus, 20 appartiennent à l'utilisateur A, tandis que 5 appartiennent à l'utilisateur B. L'utilisateur B est désavantagé, car A reçoit plus de puissance processeur que B. La planification de groupe tente d'éliminer ce problème. Il essaie d’abord d’être juste envers un groupe, puis avec les tâches individuelles de ce groupe. Ainsi, CFS avec la planification de groupe activée, allouera 50% de la CPU à chaque utilisateur A et B. La part allouée de 50% de A sera répartie entre les 20 tâches de A, tandis que les 50% restants seront répartis équitablement. parmi les 5 taks de B.

Cela s'applique maintenant à la question ci-dessus, car lorsqu'un processus génère un nouveau thread, il fait partie du groupe de planification de processus. Cela empêche un programme générant 1 000 threads d'accaparer tout le temps processeur, car il ne recevra qu'un 1 / 1001ème (1 000 threads plus le programme d'origine) du temps d'exécution de ce groupe de processus particulier.

Donc, en ralentissant le temps qu'un thread obtient par rapport à l'ensemble du système, cela punit correctement les applications threadées.

— SailorCire
source

1) Je ne trouve pas le lien ici; il faut quand même le mettre dans la réponse; 2) la citation ne parle que des utilisateurs obtenant leurs propres groupes de planification. Mais la conclusion écrite ici dissimule cela; cela implique que cela fonctionnera de la même manière lorsqu'un système ne compte qu'un seul utilisateur actif exécutant plusieurs processus.

— sourcejedi