Merci pour l'A2A.
(Note aux gentils lecteurs : Si vous ne savez pas déjà ce qu'est un blocage logiciel et comment fonctionnent les API de Windows, cette réponse va être très confuse et peu utile.)
Réponse courte : Pauvrement, par nécessité.
Réponse plus longue : Windows n'a pas de fonctionnalité intégrée spécifiquement conçue pour vérifier les blocages au moment de l'exécution. (Nous avons des outils conçus pour aider les développeurs de pilotes à diagnostiquer les bugs de deadlock, puisque les pilotes sont l'endroit où les deadlocks se produisent généralement ; mais ce n'est toujours pas quelque chose qui s'exécute sur les machines des utilisateurs finaux.)
La raison fondamentale de cela : Détecter de manière fiable un deadlock s'avère être la même chose que de résoudre le problème d'arrêt. Oui, Windows pourrait potentiellement déterminer que deux threads se bloquent mutuellement en ce moment - que le thread A a un accès exclusif en écriture sur le fichier 1 et attend le fichier 2, et que le thread B a un accès exclusif en écriture sur le fichier 2 et attend le fichier 1. Mais de nombreux programmes ont leurs propres protections anti-blocage, et même les programmes qui n'en ont pas peuvent échapper au blocage pour d'autres raisons. Le fil A ou le fil B peut libérer son verrou à tout moment, le fil C peut arriver et forcer le fil B à se terminer, ou le processus contenant le fil A peut se terminer pour une autre raison. Windows n'a aucun moyen de savoir s'il s'agit d'un véritable blocage indéfini ou simplement d'un blocage temporaire. Et pendant ce temps, si Windows utilisait des stratégies standard de résolution des blocages - briser le verrou d'un thread sur l'une des ressources, ou simplement mettre fin à l'un des threads - alors ce que les utilisateurs voient est un comportement aléatoire, incluant très probablement une perte de données, afin de résoudre un blocage qui n'était peut-être pas réel au départ.
Dans les logiciels Windows typiques, les blocages sont suffisamment rares pour qu'il soit contre-productif pour Windows de les traiter avec une stratégie plus sophistiquée que "laissez simplement les deux threads rester bloqués jusqu'à ce qu'un des programmes abandonne ou que l'utilisateur arrive et mette fin à quelque chose ou redémarre simplement l'ordinateur."