Si si, tu déplaces le problème. :) Le problème devient un problème « matériel » où la contention sur les opérations atomiques mène à une baisse de performance en cas de pas-de-bol-itude. En pratique, les algos non-bloquants, et plus généralement les algos "lock-free" garantissent que parmi tous les threads au moins un progresse, mais n'offrent aucune garantie quant à la vitesse d'exécution proprement dite. Il existe tout un tas d'études qui montrent que les algos utilisant des verrous à grain fin vont plus vite que ceux utilisant une méthode lock-free, tout bêtement parce que l'implémentation des verrous fait qu'une bonne partie des opérations peut avoir lieu en cache et pas directement en D-RAM.
Aussi, en pratique, utiliser des opérations atomiques fait gagner (pour une même charge de travail) un facteur 2 (ce qui n'est pas négligeable, j'en conviens), dans le cas où tout est optimiśe aux petits oignons (je peux retrouver des références si tu veux, et je peux aussi te rediriger vers mon collègue qui a écrit un de ces articles). Mais dans la vraie vie malheureusement, les gens ont du mal à correctement implémenter des algos non-bloquants et/ou lock-free. Herb Sutter a même écrit des articles sur le sujet.
[^] # Re: Et si un thread se fait toujours voler l'accès mémoire ?
Posté par lasher . En réponse à la dépêche IBM lance la mémoire transactionnelle dans le matériel. Évalué à 4.
Si si, tu déplaces le problème. :) Le problème devient un problème « matériel » où la contention sur les opérations atomiques mène à une baisse de performance en cas de pas-de-bol-itude. En pratique, les algos non-bloquants, et plus généralement les algos "lock-free" garantissent que parmi tous les threads au moins un progresse, mais n'offrent aucune garantie quant à la vitesse d'exécution proprement dite. Il existe tout un tas d'études qui montrent que les algos utilisant des verrous à grain fin vont plus vite que ceux utilisant une méthode lock-free, tout bêtement parce que l'implémentation des verrous fait qu'une bonne partie des opérations peut avoir lieu en cache et pas directement en D-RAM.
Aussi, en pratique, utiliser des opérations atomiques fait gagner (pour une même charge de travail) un facteur 2 (ce qui n'est pas négligeable, j'en conviens), dans le cas où tout est optimiśe aux petits oignons (je peux retrouver des références si tu veux, et je peux aussi te rediriger vers mon collègue qui a écrit un de ces articles). Mais dans la vraie vie malheureusement, les gens ont du mal à correctement implémenter des algos non-bloquants et/ou lock-free. Herb Sutter a même écrit des articles sur le sujet.