Les user-threads ne sont pas interrompus. C'est de la pure coopération. Il y a des tas de hooks dans la libc qui appellent le scheduler par exemple.
Si tu as 5 threads qui font peu de choses, les 5 commutations peuvent se faire en 1 quantum de temps processeur dans le cas des user-threads, c'est tout.
En fait, ce qui est vraiment plus rapide en mode user (et surtout consomme beaucoup moins de ressources, descripteurs de process, etc. potentiellement limités) c'est la création (et la destruction) de threads. Les commutations de contexte sont aussi [un tout petit peu] plus lentes que les commutations en mode user.
Au final, les 2 méthodes ont leur avantages et leurs inconvénients (c'est en partie pour ça qu'une solution intermédiaire a été développée d'ailleurs).
La rapidité au final est très dépendante de l'application.
Pour revenir à la news de départ, c'est le fait de ne plus utiliser GNU pth qui réduit la charge cpu, pas la manière dont sont implémentés les threads.
[^] # Re: LWPs, my mistake.
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 1.
Si tu as 5 threads qui font peu de choses, les 5 commutations peuvent se faire en 1 quantum de temps processeur dans le cas des user-threads, c'est tout.
En fait, ce qui est vraiment plus rapide en mode user (et surtout consomme beaucoup moins de ressources, descripteurs de process, etc. potentiellement limités) c'est la création (et la destruction) de threads. Les commutations de contexte sont aussi [un tout petit peu] plus lentes que les commutations en mode user.
Au final, les 2 méthodes ont leur avantages et leurs inconvénients (c'est en partie pour ça qu'une solution intermédiaire a été développée d'ailleurs).
La rapidité au final est très dépendante de l'application.
Pour revenir à la news de départ, c'est le fait de ne plus utiliser GNU pth qui réduit la charge cpu, pas la manière dont sont implémentés les threads.