Effectivement, après un petit surf, le terme LWP est défini différemment suivant les systèmes.
J'ai utilisé le terme LWP pour différentier l'approche 2 niveaux de Solaris de celles 1 niveau de Linux et OpenBSD, ce n'était pas une bonne idée.
Mais je maintiens qu'un context-switch d'un thread "noyau" est plus coûteux qu'un context-switch de threads "user" même si la différence est parfois minime. C'est la construction même du système qui veut ça.
Un thread "user" n'est pas forcément bloqué sur un accès disque, s'il y a des bons wrappers :).
De plus le coût de création/destruction est différent dans les deux cas (le cas "noyau" est plus coûteux une fois encore, plus de temps dans le noyau).
Au final, c'est un choix à faire en fonction de l'appli, comme d'habitude.
[^] # LWPs, my mistake.
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 10.
J'ai utilisé le terme LWP pour différentier l'approche 2 niveaux de Solaris de celles 1 niveau de Linux et OpenBSD, ce n'était pas une bonne idée.
Mais je maintiens qu'un context-switch d'un thread "noyau" est plus coûteux qu'un context-switch de threads "user" même si la différence est parfois minime. C'est la construction même du système qui veut ça.
Un thread "user" n'est pas forcément bloqué sur un accès disque, s'il y a des bons wrappers :).
De plus le coût de création/destruction est différent dans les deux cas (le cas "noyau" est plus coûteux une fois encore, plus de temps dans le noyau).
Au final, c'est un choix à faire en fonction de l'appli, comme d'habitude.
Un papier sur le multi-threading qui peut intéresser des gens, pour peser le pour et le contre des différentes implémentation (page 4, par exemple) :
ftp://menaik.cs.ualberta.ca/pub/TechReports/1995/TR95-23/TR95-23.p(...)
[promis, la prochaine fois je followupe en privé pour ne pas emmerder tout le monde]