11 commentaires
Si tes lectures sont largement majoritaires, std::shared_mutex est un bon début, mais attention à l'overhead du compteur de readers.
C'est exactement mon problème. En écriture, le verrouillage devient un goulot d'étranglement sévère.
As-tu envisagé de passer sur des structures de données lock-free basées sur des opérations atomiques std::atomic ?
J'ai peur de la complexité de maintenance. Est-ce que ça vaut vraiment le coup pour une structure de type std::map ?
Pour une map, regarde du côté de tbb::concurrent_hash_map de Intel. C'est ultra optimisé pour le multithreading.
Exact, ou alors utilise le sharding de mutex : au lieu d'un seul lock, tu en as 16 ou 32 basés sur le hash de la clé.
Le sharding semble être le meilleur compromis. Je vais tester avec 32 buckets pour voir l'évolution des latences.
N'oublie pas d'aligner tes mutex sur la taille d'une ligne de cache (64 octets) avec alignas(64) pour éviter le false sharing.
Ah, le false sharing ! Je n'y avais pas pensé. C'est crucial effectivement.
Utilise perf stat pour monitorer les cache-misses, tu verras tout de suite si le false sharing est la cause.
Parfait, je vais mettre en place ces optimisations et monitorer avec perf. Merci pour votre aide précieuse.
Laisser une réponse
Vous devez être connecté pour poster un message !
Je développe une application haute performance en C++ et je constate des contentions importantes sur un mutex partagé. Quel est le meilleur pattern pour minimiser l'impact du verrouillage sans risquer de race conditions ? J'ai entendu parler du
shared_mutexmais je ne suis pas sûr de l'impact en écriture fréquente.