Non je ne vois pas pourquoi se serait mutuellement exclusif, sauf problème d’implémentation :).
Si les verrous sont implémentés avec des primitives noyaux, et que la mémoire transactionnelle est implémentée au niveau du programme utilisateur, alors il n'y aura pas de problème.
J’espère que les implémentations vont permettre de coder des applications en utilisant les 2 modes!
Je vais essayer d'expliquer ma pensée:
Alors que la plupart des commentaires semblent être du type "pour ou contre la mémoire transactionnelle", je vais prendre la voie du milieu (toujours la meilleure): Ça dépend des cas et de ton application. Si tu peux valider que les accès concurrents sur une ressource sont rares, alors la mémoire transactionnelle va être super. Sinon elle va te faire perdre plus de temps et les verrous sont ta solution.
De même, rien n’empêche d'imaginer une application dans laquelle il y a plusieurs composants.
Pour tous les composants sauf un, les accès concurrents a une ressource sont rares => utilisation de la mémoire transactionnelle.
Pour le composant ou les accès concurrents sont nombreux, alors l'utilisation d'un verrou sera judicieuse même si le reste de l'application utilise une mémoire transactionnelle.
Ainsi, je pense tout a fait possible de vouloir utiliser les deux.
[^] # Re: Mémoire transactionnelle et verrous
Posté par djano . En réponse à la dépêche Sortie de la version 4.7 du compilateur GCC. Évalué à 4.
Non je ne vois pas pourquoi se serait mutuellement exclusif, sauf problème d’implémentation :).
Si les verrous sont implémentés avec des primitives noyaux, et que la mémoire transactionnelle est implémentée au niveau du programme utilisateur, alors il n'y aura pas de problème.
J’espère que les implémentations vont permettre de coder des applications en utilisant les 2 modes!
Je vais essayer d'expliquer ma pensée:
Alors que la plupart des commentaires semblent être du type "pour ou contre la mémoire transactionnelle", je vais prendre la voie du milieu (toujours la meilleure): Ça dépend des cas et de ton application. Si tu peux valider que les accès concurrents sur une ressource sont rares, alors la mémoire transactionnelle va être super. Sinon elle va te faire perdre plus de temps et les verrous sont ta solution.
De même, rien n’empêche d'imaginer une application dans laquelle il y a plusieurs composants.
Pour tous les composants sauf un, les accès concurrents a une ressource sont rares => utilisation de la mémoire transactionnelle.
Pour le composant ou les accès concurrents sont nombreux, alors l'utilisation d'un verrou sera judicieuse même si le reste de l'application utilise une mémoire transactionnelle.
Ainsi, je pense tout a fait possible de vouloir utiliser les deux.