Oui, tu peut avoir un thread qui est toujours bloqué mais, car il y a un mais comme toujours ;-) ce genre de mécanisme : instruction atomiques ou mémoire transactionelle, serve le plus souvent à implémenter des algorithmes de type "forward progress".
C'est-à-dire que en général ce qui t'intéresse c'est de garantir que de manière globale le système avance. Si ton thread échoue toujours ce n'est pas grave car à chaque fois qu'il échoue cela veut dire qu'un autre à réussi et donc que globalement le système à progressé.
Et si tu gère bien le truc, en général tu as de bonne garanties probabilistes sur les progres de chaque threads. Du style la probabilité d'échouer d'un thread décroit de manière quadratique avec le nombre d'échec ou ce genre de choses.
Si tu as besoin de garanties plus fortes comme dans le cas d'un système temps réél, il faut passer à d'autres méthodes. Mais le besoin en garanties plus fortes est relativement rare en comparaison des besoins satisfait par le forward progress, et surtout c'est beaucoup plus compliqué à gérer donc tu as très peu de chances de voir ça arriver dans du hardware rapidement.
[^] # Re: Et si un thread se fait toujours voler l'accès mémoire ?
Posté par beagf . En réponse à la dépêche IBM lance la mémoire transactionnelle dans le matériel. Évalué à 2.
Oui, tu peut avoir un thread qui est toujours bloqué mais, car il y a un mais comme toujours ;-) ce genre de mécanisme : instruction atomiques ou mémoire transactionelle, serve le plus souvent à implémenter des algorithmes de type "forward progress".
C'est-à-dire que en général ce qui t'intéresse c'est de garantir que de manière globale le système avance. Si ton thread échoue toujours ce n'est pas grave car à chaque fois qu'il échoue cela veut dire qu'un autre à réussi et donc que globalement le système à progressé.
Et si tu gère bien le truc, en général tu as de bonne garanties probabilistes sur les progres de chaque threads. Du style la probabilité d'échouer d'un thread décroit de manière quadratique avec le nombre d'échec ou ce genre de choses.
Si tu as besoin de garanties plus fortes comme dans le cas d'un système temps réél, il faut passer à d'autres méthodes. Mais le besoin en garanties plus fortes est relativement rare en comparaison des besoins satisfait par le forward progress, et surtout c'est beaucoup plus compliqué à gérer donc tu as très peu de chances de voir ça arriver dans du hardware rapidement.