Bravo! Tu viens de démontrer que les verrous fonctionnent mieux si tu as des fils d’exécution qui accèdent a la même ressource :)
Sauf que la mémoire transactionnelle c'est du verrouillage optimiste, c'est a dire que si la majorité de ton code s’exécute sans conflit, alors cela te fait gagner du temps (Et ce sont des maux de tête évités au développeur). Cette technique existe déjà avec les bases de données ou lors de chaque mise a jour d'une ligne, tu vérifies sa pour être sur tu as bien travaillé avec la version la plus a jour:
UPDATEMA_TABLEWHEREMA_COLONNE='nouvelle valeur'ANDVERSION=3-- c’était la dernière version lue depuis la base de donnée
ou bien:
UPDATEMA_TABLEWHEREMA_COLONNE='nouvelle valeur'ANDLAST_UPDATE_DATE='23/03/2012 14:57:23'-- c’était la date de dernière mise a jour lue depuis la base de donnée
Si ça foire, et bien tu rééxecute ta transaction, mais c'est pas un drame car ça arrive relativement peu souvent.
Quoiqu'il en soit, je préfères utiliser des algorithmes lock free lorsque c'est possible, c'est beaucoup plus sympa pour la maintenance :)
[^] # Re: Exemple de gain avec la mémoire transactionnelle ?
Posté par djano . En réponse à la dépêche Sortie de la version 4.7 du compilateur GCC. Évalué à 4.
Bravo! Tu viens de démontrer que les verrous fonctionnent mieux si tu as des fils d’exécution qui accèdent a la même ressource :)
Sauf que la mémoire transactionnelle c'est du verrouillage optimiste, c'est a dire que si la majorité de ton code s’exécute sans conflit, alors cela te fait gagner du temps (Et ce sont des maux de tête évités au développeur). Cette technique existe déjà avec les bases de données ou lors de chaque mise a jour d'une ligne, tu vérifies sa pour être sur tu as bien travaillé avec la version la plus a jour:
ou bien:
Si ça foire, et bien tu rééxecute ta transaction, mais c'est pas un drame car ça arrive relativement peu souvent.
Quoiqu'il en soit, je préfères utiliser des algorithmes lock free lorsque c'est possible, c'est beaucoup plus sympa pour la maintenance :)