Je lis pthread man et vois ce qui suit:
Avec NPTL, tous les threads d'un processus sont placés dans le même groupe de threads; tous les membres d'un groupe de discussion partagent le même PID.
Mon architecture actuelle fonctionne sur NPTL 2.17 et quand j'exécute htop qui affiche des threads, je vois que tous les PID sont uniques. Mais pourquoi? Je m'attends à ce que certains d'entre eux (par exemple, Chrome) partagent le même PID?
4 Réponses :
Voir man gettid :
gettid () renvoie l'ID de fil de l'appelant (TID). Dans un seul thread processus, l'ID de thread est égal à l'ID de processus (PID, tel que renvoyé par getpid (2)). Dans un processus multithread, tous les threads ont le même PID, mais chacun a un TID unique. Pour plus de détails, consultez le discussion de CLONE_THREAD dans clone (2).
Ce que htop montre est TID , pas PID . Vous pouvez activer / désactiver l'affichage des threads avec la touche H .
Vous pouvez également activer la colonne PPID dans htop et qui affiche le PID / TID du thread principal pour les threads.
Google documentation pour Chromium (qui fonctionne probablement de la même manière que Chrome en ce qui concerne ces concepts) indique qu'ils utilisent une" architecture multi-processus ". Votre citation de la page de manuel de pthread indique que tous les threads d'un même processus sont placés sous le même PID, ce qui ne s'appliquerait pas à l'architecture de Chrome.
Tu n'as pas tort. Cependant, ces enregistrements verts google / chrome dans la capture d'écran htop ne sont pas des processus mais des threads.
@MaximEgorushkin Dans l'image actuellement publiée, un examen superficiel semble montrer au moins 22 processus Chrome différents, basés sur les variations de VIRT , RES et SHR valeurs de mémoire. Il n'y a que deux groupes qui peuvent éventuellement être plusieurs threads dans le même processus: les deux premiers répertoriés peuvent éventuellement être des threads dans le même processus, et les trois avec une courte ligne de commande composée uniquement de / opt / google / chrome / chrome peut également être un seul processus. Toutes les autres instances de Chrome semblent s'exécuter dans des espaces d'adressage de tailles différentes, ce qui en fait des processus distincts.
Le noyau Linux a le concept de pids POSIX (explorable dans / proc / * ) mais il les appelle identifiants de groupe de threads dans la source du noyau et il fait référence à ses identifiants de thread internes comme pid s (explorable dans / proc / * / task / * ).
Je crois que cela est enraciné dans le traitement original par Linux des threads comme de "simples processus" qui partagent des espaces d'adressage et un tas d'autres choses entre eux.
Votre outil utilisateur propage probablement cette terminologie peut-être déroutante du noyau Linux.
Parce que les threads au niveau du noyau ne sont rien de plus que des processus avec (presque) le même espace d'adressage.
Cela a été "résolu" par le développement du noyau Linux en les renommant les processus en "threads", le "pid" -s en "tid" -s, et les anciens processus sont devenus des "groupes de threads".
Cependant, la triste vérité est que si vous créez le thread sous Linux ( clone () ), il créera un processus - en utilisant uniquement les (presque) mêmes segments de mémoire.
Cela signifie un modèle de filetage 1: 1. Cela signifie que tous les threads sont en fait des threads au niveau du noyau, ce qui signifie qu'ils sont essentiellement des processus dans le même espace d'adressage.
D'autres alternatives seraient:
Autrefois, Linux avait un modèle N: M (ngpt), mais il a été supprimé sur une autre solution de secours. C'était que les appels au noyau Linux sont intrinsèquement synchrones (bloquants). Par conséquent, une certaine coopération du noyau était nécessaire même pour la synchronisation de l'espace utilisateur. Personne ne voulait faire ça.
Il en est de même.
P.s. pour créer une application performante, vous devez en fait éviter de créer beaucoup de threads à la fois. Vous devez utiliser un pool de threads avec des protocoles de verrouillage bien pensés. Si vous ne minimisez pas l'utilisation des créations / jointures de threads, votre application sera lente et inefficace, peu importe qu'elle soit N: M ou non.