Le problème des mutex n'est généralement pas leur coût au moment du lock et du unlock. A ce niveau c'est plutôt devenu très rapide sur un mutex de base. (pas de lock récursif ou autres)
Le soucis c'est plutôt que les mutex sont pessimiste, tu doit faire un lock même si il y a très peu de chances qu'il soit nécessaire.
La mémoire transactionelle est plutôt à comparer à l'instruction compare-and-swap. Tu fais tout ton calcul comme s'il n'allait pas y avoir de problèmes, et au moment de stocker le résultat, tu vérifie juste que personne n'a fait de connerie pendant ce temps.
En gros :
tu lis la valeur de départ
tu fais ton calcul
tu stocke le résultat si personne n'a modifié la valeur de départ.
Si la probabilité que de thread modifient la même zonne est très basse, en général tu n'as pas à recommencer ton calcul.
Cette stratégie permet d'éviter les mutex et donc le cout associé aux lock, et surtout permet de ce passer complètement du lock, donc tu n'empêche pas un autre thread de bosser.
C'est particulièrement efficace dans le cas ou tu as un grand vecteur de valeur qui peuvent être modifiées. Avec des mutex, soit tu as un mutex pour tout le vecteur, et donc si tu modifie une seule valeur, tu empêches les autres threads de modifier les autres valeurs, voir de les lires, soit tu as un mutex par valeur et ça deviens très couteux.
Avec la mémoire transactionnelle tu n'as plus ce problème.
Par contre il faut que le calcul ne soit pas trop lourd, réversible et atomisable. Et surtout il faut que la probabilité de conflit soit basse: c'est-à-dire être dans une situation optimiste.
C'est par exemple le cas d'une table de hashage lock-free.
[^] # Re: Méthode coûteuse
Posté par beagf . En réponse à la dépêche IBM lance la mémoire transactionnelle dans le matériel. Évalué à 9.
Le problème des mutex n'est généralement pas leur coût au moment du lock et du unlock. A ce niveau c'est plutôt devenu très rapide sur un mutex de base. (pas de lock récursif ou autres)
Le soucis c'est plutôt que les mutex sont pessimiste, tu doit faire un lock même si il y a très peu de chances qu'il soit nécessaire.
La mémoire transactionelle est plutôt à comparer à l'instruction compare-and-swap. Tu fais tout ton calcul comme s'il n'allait pas y avoir de problèmes, et au moment de stocker le résultat, tu vérifie juste que personne n'a fait de connerie pendant ce temps.
En gros :
Si la probabilité que de thread modifient la même zonne est très basse, en général tu n'as pas à recommencer ton calcul.
Cette stratégie permet d'éviter les mutex et donc le cout associé aux lock, et surtout permet de ce passer complètement du lock, donc tu n'empêche pas un autre thread de bosser.
C'est particulièrement efficace dans le cas ou tu as un grand vecteur de valeur qui peuvent être modifiées. Avec des mutex, soit tu as un mutex pour tout le vecteur, et donc si tu modifie une seule valeur, tu empêches les autres threads de modifier les autres valeurs, voir de les lires, soit tu as un mutex par valeur et ça deviens très couteux.
Avec la mémoire transactionnelle tu n'as plus ce problème.
Par contre il faut que le calcul ne soit pas trop lourd, réversible et atomisable. Et surtout il faut que la probabilité de conflit soit basse: c'est-à-dire être dans une situation optimiste.
C'est par exemple le cas d'une table de hashage lock-free.