多线程应用程序中检查死锁的方法
WIN32 API的好的特性就是能够让你所有可能引起死锁的资源。在上面的WINDOWS3.1的例子中，硬盘驱动器制造商，应用程序员，WINDOWS开发人员都不可能预测到死锁，因为这个死锁包含了几个软件部分，而且软件内部的功能对其他部分的作者来说是未知的，但如果把他们放在一起，他们就能够让系统挂起。
然而在WIN32 API中，所有的同步对象只能在本地工作，也就是说，他们不能影响那些决定共享他们的线程，因此也不存在能够声明在VMM 或OS/2中的全局关键代码段，从而被系统中的其他线程挂起。在NT上，由于你编写代码的粗心，你可能被死锁的一个或几个应用程序，但其他的系统程序不会受影响，这增加了安全和可靠性。
基本上，检查死锁使用两种方法的一种：程序死锁后的检查和不变的检查；死锁后的策略在前面已经解释了：发布一个产品，等到死锁发生以后来，而通过预先设置的字段来指示可能的死锁条件，然后在下一个版本中修改（我敢确信这不是所有公司都使用的深思熟虑的好办法，它有一个严重的副作用就是，不能有足够的时间来做正式的分析）。
为了解析不变的方法，让我们来回到GOOFY例子，即使不运行GOOFY，我们也能够立即检查可能出现的死锁，我们所需要的就是证明死锁发生的条件，确切的说是当一个线程拥有关键代码段1并等待关键代码段2，这个时候另外一个线程拥有关键代码段2却等待关键代码段1。我们很容易的就可以证明GOOFY中存在我们描述的死锁条件，但相反的情况，也就是我们很难证明一个线程不包含死锁条件。让我们来看看GOOFY2，是对GOOFY的一个修改版。GOOFY2看起来与GOOFY非常的相似，仅仅在生命关键代码段的时候以嵌入式的方式（声明A，声明B，释放B，释放A），两个线程都是首先声明关键段1然后声明关键段2，有效地复制了关键段1。这从变成的角度来看没有什么意义，但它符合我们前面描述的观点（这也是我为什么叫他做GOOFY的原因）。
Long WINAPI ThreadFn(long lParam)
{
while(TRUE)
{EnterCriticalSection(&cs1); // change!
printf("\nThread2 has entered Critical Section 1 but not 2.");
EnterCriticalSection(&cs2); // change!
printf("\nThread2 has entered Critical Section 1 and 2!");
LeaveCriticalSection(&cs2); // change!
printf("\nThread2 has left Critical Section 2 but still owns 1.");
LeaveCriticalSection(&cs1); // change!
printf("\nThread2 has left both critical sections...");
Sleep(20);
};
}
我们强烈的感觉GOOFY2不会死锁，但我们能除了感觉能做到更好吗？我们能证明GOOFY2不会死锁吗？或者不使用许多希腊字母和限于你航空技术研究生学位的论证？
让我们对GOOFY2的控制流程做说明。首先，定义关键段是要不关键段1是自由的，要不线程1或线程已经声明了关键段1，同样，因为关键段1也仅仅在他是自由的时候才能被声明，并且关键段1唯一自由的地方就是两个线程都各自执行它while循环前面的部分，我们可以安全的说，关键段1是自由的或者一个线程已经拥有了它，并且另一个线程必须执行while循环到EnterCriticalSection(&cs1)之间的代码，同时等待声明关键段1。同样关键段2只能在关键段1之后开始声明，无论在什么时候如果拥有关键段2，就必须拥有前面的关键段1，拥有关键段2的线程必须执行EnterCriticalSection(&cs2)和EnterCriticalSection(&cs2) 之间的代码，而其他的线程同时只能执行while循环前面的代码并等待关键段。
现在死锁发生的唯一条件就是如果线程A被另外一个线程B拥有的资源挂起，而同时A轮流拥有一个B等待的关键段。然后，从我们的直觉来判断，一旦任何线程拥有了任何关键段，我们可以断定，其他的线程必须等待关键段1，因此，线程要么拥有一个关键段，要么就没有，从而因此两个线程各自拥有一个关键段的情况不会出现（死锁的必要条件）。
结束了吗？是的，除了我们必须证明我们的直觉是正确的之外，我们将来需要回忆。如果你已经遵从这个论证，你可能在毕业报告上面得到800+的分数。
你可能不知道，上面的讨论实际上是有相当的学术称谓“不变的分析”，你可能记得，我们讨论的在多线程应用程序中检查死锁的第二种方法。
