[Note: je parle de Linux standard, sans ajout de librairies spécialisées pour d'autres modèles d'ordonnancement]
[goto "Conclusion" pour les décideurs]
Oui mais pas vraiment des LWP.
Tu crée n processus qui partagent le même espace d'adressage mais qui sont des processus différents (on les voit avec ps). Ce qui est lourd c'est le context switch qui correspond à un passage dans le noyau plus diverses recopies de bidules et de machins.
Tu ne peux pas (encore une fois, je ne pouvais pas la dernière fois que j'ai essayé) avoir plusieurs threads au sein d'un seul processus. C'est à dire plusieurs fils d'éxécution dans un seul processus (toujours au sens noyau, visible par ps) (à moins d'utiliser GNU pth, peut-être, mais GNU pth, bon, si on peut éviter ...).
Les threads léger gèrent leur ordonnancement de manière interne au processus, sans passage dans le noyau, ce qui est moins couteux. Or Linux ne permet (permettait ?) pas de faire cela en standard.
Ce n'est pas une critique négative, ça a ses avantages aussi.
Ce ne sont pas des LWP, mais des threads « kernel-based » si on peut dire. La dénomination LWP est spécifique à Solaris et autres systèmes utilisant le même système de threading à 2 niveau (IRIX notamment (en tout cas sur la dernière Onyx que j'ai touchée), d'autres à vérifier).
Bref, ce ne sont pas des LWP (ça j'en suis sûr), et la puissance de l'ordonnanceur est gratuite pour le développeur mais a un coût à l'utilisation : le guichet du noyau. Dans le cas des threads au niveau utilisateur (par ex, pthreads OpenBSD) il n'y a pas de passage dans le noyau, en contrepartie le quantum de temps pour chaque thread est plus réduit.
Exemples :
Un processus A avec 2 threads A1&A2,
Un autre processus B
------> t
Sous Linux (ou équivalent de ce point de vue) : |<- proc B ->|<- thr A1 ->|<- thr A2 ->|<- proc B ->| ...
Sous OpenBSD (ou équivalent de ce point de vue) : |<- proc B ->|<- proc A ->|<- proc B ->|...
avec sur le temps de A : |<-------- proc A ------->|
|<- thr A1 ->|<- thr A2 ->|
Sous Solaris on peut avoir 2 threads sur un processus noyau et 1 autre thread du même groupe sur un autre processus noyau :
|<------- un seul code ------->
|<-- proc A -->|<-- proc B -->|
|<-t1->|<-t2 ->|<-- thr 3 --->|
Conclusion :
La méthode style Solaris est pas mal pour les archis multi-processeurs (notamment le système de noeuds avec mémoire distribuée sur certaines machines SGI), bon compromis.
Sous Linux, comme le SMP est géré, la méthode est adaptée aussi. Sous OpenBSD, le SMP n'est pas (encore) géré donc la méthode est adaptée. Le jour où le SMP sera géré sous Open, les threads légers gérés au niveau utilisateur ne se répartiront pas les processeurs, il resteront sur un seul car un seul processus au sens du noyau existera.
[^] # Re: Autres applis et pthreads
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 10.
[goto "Conclusion" pour les décideurs]
Oui mais pas vraiment des LWP.
Tu crée n processus qui partagent le même espace d'adressage mais qui sont des processus différents (on les voit avec ps). Ce qui est lourd c'est le context switch qui correspond à un passage dans le noyau plus diverses recopies de bidules et de machins.
Tu ne peux pas (encore une fois, je ne pouvais pas la dernière fois que j'ai essayé) avoir plusieurs threads au sein d'un seul processus. C'est à dire plusieurs fils d'éxécution dans un seul processus (toujours au sens noyau, visible par ps) (à moins d'utiliser GNU pth, peut-être, mais GNU pth, bon, si on peut éviter ...).
Les threads léger gèrent leur ordonnancement de manière interne au processus, sans passage dans le noyau, ce qui est moins couteux. Or Linux ne permet (permettait ?) pas de faire cela en standard.
Ce n'est pas une critique négative, ça a ses avantages aussi.
Ce ne sont pas des LWP, mais des threads « kernel-based » si on peut dire. La dénomination LWP est spécifique à Solaris et autres systèmes utilisant le même système de threading à 2 niveau (IRIX notamment (en tout cas sur la dernière Onyx que j'ai touchée), d'autres à vérifier).
Bref, ce ne sont pas des LWP (ça j'en suis sûr), et la puissance de l'ordonnanceur est gratuite pour le développeur mais a un coût à l'utilisation : le guichet du noyau. Dans le cas des threads au niveau utilisateur (par ex, pthreads OpenBSD) il n'y a pas de passage dans le noyau, en contrepartie le quantum de temps pour chaque thread est plus réduit.
Exemples :
Un processus A avec 2 threads A1&A2,
Un autre processus B
------> t
Sous Linux (ou équivalent de ce point de vue) :
|<- proc B ->|<- thr A1 ->|<- thr A2 ->|<- proc B ->| ...
Sous OpenBSD (ou équivalent de ce point de vue) :
|<- proc B ->|<- proc A ->|<- proc B ->|...
avec sur le temps de A :
|<-------- proc A ------->|
|<- thr A1 ->|<- thr A2 ->|
Sous Solaris on peut avoir 2 threads sur un processus noyau et 1 autre thread du même groupe sur un autre processus noyau :
|<------- un seul code ------->
|<-- proc A -->|<-- proc B -->|
|<-t1->|<-t2 ->|<-- thr 3 --->|
Conclusion :
La méthode style Solaris est pas mal pour les archis multi-processeurs (notamment le système de noeuds avec mémoire distribuée sur certaines machines SGI), bon compromis.
Sous Linux, comme le SMP est géré, la méthode est adaptée aussi. Sous OpenBSD, le SMP n'est pas (encore) géré donc la méthode est adaptée. Le jour où le SMP sera géré sous Open, les threads légers gérés au niveau utilisateur ne se répartiront pas les processeurs, il resteront sur un seul car un seul processus au sens du noyau existera.
J'éspère ne pas avoir fait de fautes.