[Précédent (date)] [Suivant (date)] [Précédent (sujet)] [Suivant (sujet)] [Index par date] [Index par sujet]
Re: Thread Linux
- To: Liste Générale LQ <>
- Subject: Re: Thread Linux
- From: (Fabien Ninoles)
- Date: Tue, 26 Jun 2001 02:35:47 -0400 (EDT)
-
In-reply-to: <[email protected]>
Réponse simple:
Il n'y a pas vraiment moyen de déterminer si une tâche est un processus
ou une thread. Le noyau ne fait pas de différence entre les deux et
laisse aux librairies le soin de décider comme les ressources seront
partagés. ps n'a pas vraiment le choix donc d'afficher les mêmes
quantités pour chaque thread puisqu'effectivement, chaque thread utilise
cette même quantité de mémoire. Seulement, elles se le partagent entre
elles. Par exemple, si une famille de 4 personnes vit dans un logement
5 pièces et qu'on demande à chaque membre de la famille combien de pièce
compte leur appartement, chacun répondra 5. Ça ne veut pas dire que le
logement compte 20 pièces! On ne s'attendra pas à ce qu'ils répondent
1.2 pour tenir compte du fait qu'elles partagent ces pièces avec
d'autres personnes! Ce sera d'autant plus difficile que chaque pièce
est utilisé par plusieurs membres à la fois ou indifféremment.
Réponse complète.
Linux utilise des coprocessus pour ces threads car le task switching (le
moment où le noyau abandonne un processus pour donner un peu de temps à
un autre) ne coûte pratiquement rien sous Linux contrairement à d'autres
OS. La seule différence avec un fork (la fonction qui permet de partir
un autre processus avec une mémoire différente) est que la mémoire
globale est partagée dans les threads mais pas dans le fork (il y a
d'autres différences aussi entre autres au niveau des signaux mais je ne
rentrerai pas dans ces détails ici). Au niveau du noyau, c'est la même
chose: la fonction clone est appelée, on crée une nouvelle tâche, et on
copie les éléments demander. Pour le noyau, ce sont 2 processus
distincts, peu importe les ressources qu'ils partagent ou non. Notez
que je parle de l'implémentation de LinuxThreads fournit avec glibc, et
non pas celle de GNU Pthread (qui, si je ne me trompe pas, implémente les
threads dans une seule tâche, faisant lui même le task switching. Mais
là, je laisse le soin aux gens de vérifier par eux mêmes, ça fait
longtemps que j'aie vu ça).
Lorsque ps lit les informations contenu dans /proc pour déterminer les
processus qui roulent et leur utilisation des ressources, ils demandent
à chaque tâche du noyau combien de mémoire qu'elle utilise. Les
threads d'un même processus utilisent la même mémoire, c'est donc
normale qu'elles répondent toutes les deux la même chose et donne la
FAUSSE impression que le processus entier utilisent deux fois plus de
mémoire. C'est la même chose pour la mémoire partagée interprocessus
(IPC), très utilisé avec XWindows pour des raisons d'efficacité. Comme
à la fois X11 et Gimp partagent une même section de mémoire, les deux
considère qu'ils utilisent la même région en mémoire, aucun des deux
n'ayant priorité sur l'autre. De plus, X11 utilisent aussi la mémoire
de la carte vidéo. Hors, pour le processus, cette mémoire de
périphériques n'est aucunement différente de la mémoire RAM de votre PC.
Elle a simplement une adresse différente déterminer par le noyau.
On Sun, Jun 24, 2001 at 01:32:52PM -0400, Benoit Goudreault-Emond wrote:
> >>>>> "HJL" == Herve J Lombaert <[email protected]> writes:
>
> HJL> Bonjour,
> HJL> J'aimerais savoir s'il y a une raison particulière pour que linux gère
> HJL> les threads comme des processus. Je pensais que l'un des avantages
> HJL> d'utiliser un thread est le partage des ressources, d'où viendrait donc
> HJL> l'intérêt de dédoubler la mémoire pour chaque thread ?
>
> HJL> Simple curiosité qui me turlupine à chaque fois que je fais un "ps -A"
> HJL> ;-)
>
> Il est possible que ps -A compte la mémoire partagée avec le processus
> parent comme faisant parti du thread également; toutefois, ce n'est
> que pour des raisons de comptabilité de resources. La mémoire est
> belle et bien partagée---sinon, il serait impossible pour les threads
> de communiquer les uns avec les autres sans recourir à des systèmes
> plus lourds commes les pipes. Dans ce cas, il ne resterait plus qu'à
> utiliser les processus---c'est plus stable, et pas beaucoup plus lourd
> a part pour la communication entre les différents agents.
>
> --
> Benoit Goudreault-Emond -- Reply to: [email protected]
> CoFounder, KMS Group. Developer, Silanis Technology (http://www.silanis.com)
> A proud user of Linux---I'd rather work than nursemaid my computer.
> My homepage (such as it is): http://www.crosswinds.net/~bge
--
-------------------------------* *-------------------------
Fabien Niñoles / / [email protected]
Chevalier Servant de Sa Dame / / C15D FE9E BB35 F596 127F
Veneur Gris par la Clef / / BF7D 8F1F DFC9 BCE0 9436
Développeur pour Debian / / http://www.tzone.org/~fabien
--------------------------* *------------------------------