Pourquoi un mutex de pthread est-il considéré comme "plus lent" qu'un futex ?

Question

Pourquoi les mutex POSIX sont-ils considérés comme plus lourds ou plus lents que les futex ? D'où vient la surcharge du type de mutex de pthread ? J'ai entendu dire que les mutex pthreads sont basés sur les futex et que, lorsqu'ils ne sont pas contestés, ils ne font aucun appel au noyau. Il semble donc qu'un pthread mutex soit simplement un "emballage" autour d'un futex.

La surcharge est-elle simplement due à l'appel de la fonction enveloppante et à la nécessité pour la fonction mutex de "configurer" le futex (c'est-à-dire, en gros, la configuration de la pile pour l'appel de la fonction mutex de pthread) ? Ou bien y a-t-il des étapes supplémentaires de barrière mémoire avec le pthread mutex ?

Answer 1

Les futex ont été créés pour améliorer les performances des mutex des pthreads. NPTL utilise les futex, LinuxThreads a précédé les futex, et je pense que c'est de là que vient la considération "plus lente". Les mutex NPTL peuvent avoir une surcharge supplémentaire, mais cela ne devrait pas être beaucoup.

Edit : Les frais généraux réels consistent essentiellement en :

• sélection de l'algorithme correct pour le type de mutex (normal, récursif, adaptatif, contrôle d'erreur ; normal, robuste, héritage prioritaire, protégé par priorité), où le code indique fortement au compilateur que nous utilisons probablement un mutex normal (il doit donc le transmettre à la logique de prédiction de branchement du CPU),
• et une écriture du propriétaire actuel du mutex si nous parvenons à le prendre, ce qui devrait normalement être rapide, puisqu'il réside dans la même ligne de cache que le verrou que nous venons de prendre, à moins que le verrou ne soit très disputé et qu'un autre CPU ait accédé au verrou entre le moment où nous l'avons pris et celui où nous avons tenté d'écrire le propriétaire (cette écriture n'est pas nécessaire pour les mutex normaux, mais nécessaire pour les mutex récursifs et de contrôle d'erreur).

Donc, quelques cycles (cas typique) à quelques cycles + une mauvaise prédiction de branche + une absence supplémentaire de cache (cas le plus défavorable).

Answer 2

La réponse courte à votre question est que les futex sont connus pour être implémentés aussi efficacement que possible, alors qu'un mutex de pthread peut l'être ou non. Au minimum, un mutex pthread a une surcharge associée à la détermination du type de mutex et les futex n'en ont pas. Ainsi, un futex sera presque toujours au moins aussi efficace qu'un mutex de pthread, jusqu'à ce que quelqu'un pense à une structure plus légère qu'un futex et publie ensuite une implémentation de pthreads qui l'utilise comme mutex par défaut.

Answer 3

Techniquement parlant, les mutex de pthread ne sont pas plus lents ou plus rapides que les futex. pthread n'est qu'une API standard, donc le fait qu'ils soient lents ou rapides dépend de l'interface de l'API. de cette API .

Spécifiquement dans Linux, les mutex pthread sont implémentés comme des futex et sont donc rapides. En fait, vous ne voulez pas utiliser l'API futex elle-même car elle est très difficile à utiliser, ne dispose pas des fonctions wrapper appropriées dans la glibc et nécessite un codage en assembleur qui ne serait pas portable. Heureusement pour nous, les mainteneurs de la glibc ont déjà codé tout cela pour nous sous le capot de l'API mutex de pthread.

Maintenant, parce que la plupart des systèmes d'exploitation n'a pas mis en œuvre les futex ce que les programmeurs entendent généralement par pthread mutex, c'est la performance que vous obtenez de l'implémentation habituelle des pthread mutex, c'est-à-dire plus lente.

C'est donc un fait statistique que dans la plupart des systèmes d'exploitation conformes à POSIX, le mutex pthread est implémenté dans l'espace du noyau et est plus lent qu'un futex. Sous Linux, ils ont les mêmes performances. Il se peut qu'il existe d'autres systèmes d'exploitation où les mutex pthread sont implémentés dans l'espace utilisateur (dans le cas non prévu) et ont donc de meilleures performances, mais je ne connais que Linux pour le moment.

Answer 4

Parce qu'ils restent dans l'espace utilisateur autant que possible, ce qui signifie qu'ils nécessitent moins d'appels système, ce qui est intrinsèquement plus rapide car le changement de contexte entre le mode utilisateur et le mode noyau est coûteux.

Je suppose que vous parlez de Noyau threads quand on parle de threads POSIX. Il est tout à fait possible d'avoir une implémentation entièrement en espace utilisateur des threads POSIX qui ne nécessitent pas d'appels système mais qui présentent d'autres problèmes.

Je crois savoir qu'un futex est à mi-chemin entre un thread POSIX du noyau et un thread POSIX de l'espace utilisateur.

Answer 5

Sur AMD64, un futex est de 4 octets, alors qu'un pthread_mutex_t NPTL est de 56 octets ! Oui, il y a un surcoût important.