Ce n'est pas pareil.
Le problème qu'il décrit est un genre de livelock. Mais en pratique cela ne se produit pas, parce que statistiquement, au bout d'un certain temps, tu n'auras qu'un thread actif au sein de la section critique (qui est censée être courte), ou du moins tu n'auras pas de thread en train de modifier les donnés protégées.
Dans le cas que tu décris, effectivement, en cas de forte contention, en théorie tu peux avoir un problème de "starvation", où un thread se fait griller par ses petits copains ad vitam.
Mais c'est une question d'implémentation: par exemple, POSIX garantit ceci (man pthread_mutex_unlock):
"""If there are threads blocked on the mutex object referenced by mutex when pthread_mutex_unlock() is called, resulting in the mutex becoming available, the scheduling policy is used to determine which thread shall acquire the mutex."""
Le point important est "the scheduling policy" : c'est l'ordonnanceur qui choisit le thread qui va acquérir le mutex, et si un threads reste en attente trop longtemps sur un mutex, sa priorité finit par être plus importante que celle de ses amis.
Au passage, il y a un mécanisme de synchronisation utilisé par le noyau Linux qui se rapproche de STM : les seqlocks (il y a un lock utilisé pour les writers, mais pas de locks pour les readers).
Enfin, l'implémentation "STM" pour CPython d'Armin Rigo n'est pas vraiment (du tout) une forme de STM : elle se contente de garder le GIL locké (donc pas de concurrence, pas de notion de commit/rollback, c'est en fait un gros verrou global "implicite"). En plus elle présente pas mal de risques de deadlocks...
[^] # Re: Et si un thread se fait toujours voler l'accès mémoire ?
Posté par neologix . En réponse à la dépêche IBM lance la mémoire transactionnelle dans le matériel. Évalué à 4.
Ce n'est pas pareil.
Le problème qu'il décrit est un genre de livelock. Mais en pratique cela ne se produit pas, parce que statistiquement, au bout d'un certain temps, tu n'auras qu'un thread actif au sein de la section critique (qui est censée être courte), ou du moins tu n'auras pas de thread en train de modifier les donnés protégées.
Dans le cas que tu décris, effectivement, en cas de forte contention, en théorie tu peux avoir un problème de "starvation", où un thread se fait griller par ses petits copains ad vitam.
Mais c'est une question d'implémentation: par exemple, POSIX garantit ceci (man pthread_mutex_unlock):
"""If there are threads blocked on the mutex object referenced by mutex when pthread_mutex_unlock() is called, resulting in the mutex becoming available, the scheduling policy is used to determine which thread shall acquire the mutex."""
Le point important est "the scheduling policy" : c'est l'ordonnanceur qui choisit le thread qui va acquérir le mutex, et si un threads reste en attente trop longtemps sur un mutex, sa priorité finit par être plus importante que celle de ses amis.
Au passage, il y a un mécanisme de synchronisation utilisé par le noyau Linux qui se rapproche de STM : les seqlocks (il y a un lock utilisé pour les writers, mais pas de locks pour les readers).
Enfin, l'implémentation "STM" pour CPython d'Armin Rigo n'est pas vraiment (du tout) une forme de STM : elle se contente de garder le GIL locké (donc pas de concurrence, pas de notion de commit/rollback, c'est en fait un gros verrou global "implicite"). En plus elle présente pas mal de risques de deadlocks...