Contexte et objectif
Un benchmark Rust a évalué l’impact du RwLock dans une charge de travail fortement orientée lecture. L’objectif était de mesurer comment la contention sur les verrous affecte le nombre d’opérations de lecture par seconde et d’explorer une alternative basée sur le crate Crossbeam.
Mise en œuvre du benchmark
Le test a simulé 16 384 acquisitions de RwLock par élément, chaque acquisition étant suivie d’une lecture de donnée immuable. Deux configurations ont été comparées : la première utilise le std::sync::RwLock classique, la seconde remplace chaque acquisition par un epoch guard de Crossbeam et un chargement atomique du pointeur. Aucun changement n’a été apporté au code métier, seules les primitives de synchronisation ont été substituées.
Analyse des résultats
Avec le RwLock standard, le débit mesuré s’établit à 15 930 opérations/s. En remplaçant les verrous par un epoch guard, le même scénario atteint 229 070 opérations/s, soit une multiplication par 14,4. Cette hausse provient de la réduction du coût d’acquisition : le RwLock implique un passage en mode exclusif pour chaque lecture, générant des cycles de synchronisation et des cache misses. L’approche epoch‑based évite ces transitions en conservant un pointeur atomique partagé, ce qui minimise les accès au cache et élimine les barrières de mémoire fréquentes.
Le benchmark indique également que le RwLock reste performant lorsqu’il y a peu de lecteurs simultanés ou que les écritures sont fréquentes, car le verrou exclusif garantit la cohérence des données. En revanche, dans un scénario où les écritures sont rares (moins de 1 % du trafic), la surcharge du RwLock devient le facteur limitant.
Implications et limites
L’utilisation d’un epoch guard est pertinente pour les services à forte intensité de lecture, comme les caches en mémoire, les bases de données en‑processus ou les moteurs de recherche. Cependant, cette technique introduit une complexité supplémentaire : la gestion du cycle de vie des objets doit être assurée par le système d’epoch, sous peine de fuites ou de références pendantes. De plus, les performances d’écriture ne sont pas évaluées dans le benchmark ; les écritures nécessitent souvent une synchronisation globale qui peut annuler les gains observés en lecture.
En pratique, le choix entre RwLock et Crossbeam dépend du profil de charge. Pour les applications où le ratio lecture/écriture dépasse largement 100 : 1, le passage à Crossbeam peut réduire la latence et augmenter le débit sans modifier l’architecture logique. Dans les systèmes mixtes ou fortement écrits, il convient de conserver le RwLock ou d’explorer d’autres structures lock‑free.
