MySQL était l'appli ayant le plus de problèmes avec les pthreads. À priori elle faisait appel à une routine qui bloquait tout un processus et ses threads contenus[1] au lieu de bloquer un seul thread (ça au milieu d'autres soucis).
GTK+ tourne super bien avec les threads natifs sur x86 depuis un bout de temps, par exemple.
Les threads sont encore relativement « en développement » sous Open, surtout sur les archis non-x86. Mais ça s'améliore très vite.
Le truc, c'est que comme toutes les archis n'ont pas un support parfait, les ports sont compilé avec un mix de pthreads natifs[2] et de GNU pth [3].
[1] Sous OpenBSD les threads sont gérés dans le user space. Ce sont plusieurs fils d'éxécution qui tournent dans un seul processus. L'ordonnancement est géré via des hooks dans la libc_r. L'avantage c'est que c'est très rapide et très peu couteux. Le défaut c'est quand il reste des bugs et qu'un thread bloque tous les autres à cause d'un appel à une fonction qui bloque un processus entier.
Sous Linux, c'est (était ?) différent. Les threads sont matérialisés par des processus lourds différents. Ils sont créés par des appels type clone(2) (on peut faire l'équivalent sous Open avec rfork()). L'avantage c'est qu'il n'y a pas ce genre de problèmes d'ordonnancement car le noyau fait préemption (puisque ce sont des processus séparés). Le défaut c'est que c'est plus coûteux et moins rapide (la commutation de contexte est plus lourde).
Il existe au moins une troisième voie : les LWP (Light-Weight Processes) à la Solaris où n threads sont répartis sur m processus avec n >= m.
[^] # Autres applis et pthreads
Posté par Jean-Yves B. . En réponse à la dépêche performances MySQL sous OpenBSD. Évalué à 10.
GTK+ tourne super bien avec les threads natifs sur x86 depuis un bout de temps, par exemple.
Les threads sont encore relativement « en développement » sous Open, surtout sur les archis non-x86. Mais ça s'améliore très vite.
Le truc, c'est que comme toutes les archis n'ont pas un support parfait, les ports sont compilé avec un mix de pthreads natifs[2] et de GNU pth [3].
[1] Sous OpenBSD les threads sont gérés dans le user space. Ce sont plusieurs fils d'éxécution qui tournent dans un seul processus. L'ordonnancement est géré via des hooks dans la libc_r. L'avantage c'est que c'est très rapide et très peu couteux. Le défaut c'est quand il reste des bugs et qu'un thread bloque tous les autres à cause d'un appel à une fonction qui bloque un processus entier.
Sous Linux, c'est (était ?) différent. Les threads sont matérialisés par des processus lourds différents. Ils sont créés par des appels type clone(2) (on peut faire l'équivalent sous Open avec rfork()). L'avantage c'est qu'il n'y a pas ce genre de problèmes d'ordonnancement car le noyau fait préemption (puisque ce sont des processus séparés). Le défaut c'est que c'est plus coûteux et moins rapide (la commutation de contexte est plus lourde).
Il existe au moins une troisième voie : les LWP (Light-Weight Processes) à la Solaris où n threads sont répartis sur m processus avec n >= m.
[2] http://www.openbsd.org/cgi-bin/man.cgi?query=pthreads(...)
[3] http://www.gnu.org/software/pth/(...)