多线程应用程序中检查死锁的方法
WIN32 API的好的特性就是能够让你所有可能引起死锁的资源。在上面的WINDOWS3.1的例子中，硬盘驱动器制造商，应用程序员，WINDOWS开发人员都不可能预测到死锁，因为这个死锁包含了几个软件部分，而且软件内部的功能对其他部分的作者来说是未知的，但如果把他们放在一起，他们就能够让系统挂起。
然而在WIN32 API中，所有的同步对象只能在本地工作，也就是说，他们不能影响那些决定共享他们的线程，因此也不存在能够声明在VMM 或OS/2中的全局关键代码段，从而被系统中的其他线程挂起。在NT上，由于你编写代码的粗心，你可能被死锁的一个或几个应用程序，但其他的系统程序不会受影响，这增加了安全和可靠性。
基本上，检查死锁使用两种方法的一种：程序死锁后的检查和不变的检查；死锁后的策略在前面已经解释了：发布一个产品，等到死锁发生以后来，而通过预先设置的字段来指示可能的死锁条件，然后在下一个版本中修改（我敢确信这不是所有公司都使用的深思熟虑的好办法，它有一个严重的副作用就是，不能有足够的时间来做正式的分析）。
