Dans les cas présentés, la gestion des mutex parait très simple. Dans des cas réels un peu complexes, avec plusieurs threads occupés à des tâches qui n'ont rien à voir entre elles, partageant plusieurs ressources à coups de mutex, écrire un programme correct s'avère beaucoup plus compliqué.
Dans ce cas, la mémoire transactionnelle peut apporter une solution intéressante en terme de simplification logicielle. Je ne saurai dire en terme de performance car c'est pas trop mon rayon.
Pour prendre un cas concret, Armin Rigo, le développeur de PyPy (l'implémentation alternative de CPython) vient justement de poster un article de blog sur le sujet 1, en disant que la mémoire transactionnée serait une alternative réaliste et intéressante pour se passer du GIL. Par contre, il cite des impacts de performance assez massif, donc ça reste un sujet expérimental à ce stade.
[^] # Re: Méthode coûteuse
Posté par Philippe F (site web personnel) . En réponse à la dépêche IBM lance la mémoire transactionnelle dans le matériel. Évalué à 2.
Dans les cas présentés, la gestion des mutex parait très simple. Dans des cas réels un peu complexes, avec plusieurs threads occupés à des tâches qui n'ont rien à voir entre elles, partageant plusieurs ressources à coups de mutex, écrire un programme correct s'avère beaucoup plus compliqué.
Dans ce cas, la mémoire transactionnelle peut apporter une solution intéressante en terme de simplification logicielle. Je ne saurai dire en terme de performance car c'est pas trop mon rayon.
Pour prendre un cas concret, Armin Rigo, le développeur de PyPy (l'implémentation alternative de CPython) vient justement de poster un article de blog sur le sujet 1, en disant que la mémoire transactionnée serait une alternative réaliste et intéressante pour se passer du GIL. Par contre, il cite des impacts de performance assez massif, donc ça reste un sujet expérimental à ce stade.