Pourquoi un mutex 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 dans le type mutex pthread?J'ai entendu dire que les mutex pthread sont basés sur des futex et, lorsqu'ils ne sont pas contestés, n'effectuent aucun appel dans le noyau.Il semble alors qu'un mutex pthread n'est qu'un "wrapper" autour d'un futex.

Est-ce que la surcharge est simplement dans l'appel de fonction-wrapper et la nécessité pour la fonction mutex de "configurer" le futex (c'est-à-dire, fondamentalement, la configuration de la pile pour l'appel de la fonction mutex pthread)?Ou y a-t-il des étapes supplémentaires de barrière mémoire en cours avec le mutex pthread?

Answer 1

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 coûte cher.

Je suppose que vous parlez de threads du noyau lorsque vous parlez 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 aucun appel système mais qui ont leurs propres problèmes.

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

Answer 2

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

Modifier: 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, vérification des erreurs; normal, robuste, priorité-héritage, priorité protégée), où le code indique fortement au compilateur que nous utilisons probablement un mutex (il devrait donc transmettre cela à la logique de prédiction de branche du CPU),
• et une écriture du propriétaire actuel du mutex si nous parvenons à le prendre qui devrait normalement être rapide, car il réside dans la même ligne de cache que le verrou réel que nous venons de prendre, à moins que le verrou ne soit fortement contesté et un autre processeur a accédé au verrou entre le moment où nous l'avons pris et le moment où nous avons tenté d'écrire le propriétaire (cette écriture n'est pas nécessaire pour les mutex normaux, mais nécessaire pour la vérification des erreurs et les mutex récursifs).

Donc, quelques cycles (cas typique) à quelques cycles + une erreur de prédiction de branche + un manque de cache supplémentaire (le pire des cas).

Answer 3

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 pthread peut ou non l'être.Au minimum, un mutex pthread a une surcharge associée à la détermination du type de mutex et pas les futex.Ainsi, un futex sera presque toujours au moins aussi efficace qu'un mutex pthread, jusqu'à ce que quelqu'un invente une structure plus légère qu'un futex et publie ensuite une implémentation pthreads qui l'utilise pour son mutex par défaut.

Answer 4

Techniquement parlant, les mutex pthread ne sont ni plus lents ni plus rapides que les futex. pthread n'est qu'une API standard, donc leur lenteur ou leur rapidité dépend de la mise en œuvre de cette API .

Plus précisément sous 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, n'a pas les fonctions de wrapper appropriées dans la glibc et nécessite un codage en assembly qui ne serait pas portable. Heureusement pour nous, les responsables de la glibc ont déjà codé tout cela pour nous sous le capot de l'API pthread mutex.

Maintenant, comme la plupart des systèmes d'exploitation n'ont pas implémenté de futexes , les programmeurs entendent généralement par mutex pthread les performances que vous obtenez de l'implémentation habituelle des mutex pthread, qui est plus lente.

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

Answer 5

Sur AMD64, un futex fait 4 octets, tandis qu'un NPTL pthread_mutex_t fait 56 octets!Oui, il y a une surcharge importante.