Microsoft KB Archive/126768

{| The information in this article applies to: Microsoft Win32 Application Programming Interface (API) included with: - Microsoft Windows NT versions 3.5 and 3.51 - Microsoft Windows 95 version 4.0
 * width="100%"|

SUMMARY
Debugging a multithreaded application that deadlocks is challenging because the debugger cannot identify for you which thread owns which resource. You would have to track this information in your code. Because it is difficult to debug a deadlock situation, it is important to design your application to avoid deadlock.

This article is a brief introduction to a very complex topic. There are references at the bottom of this article for additional information.

The key point to keep in mind when designing a multithreaded program is that resources must always be requested in the same order.

MORE INFORMATION
The Win32 API provides WaitForSingleObject and WaitForMultipleObjects for requesting resources with handles. You would use a different method to request other resources, depending on the resource type.

Many deadlocks occur because resources are not requested in the same order by the application threads. For example:


 * Thread 1 holds resource A and wants resource B.
 * Thread 2 holds resource B and wants resource A.

Both threads block forever, resulting in deadlock. There are many other possible scenarios. To avoid this problem, identify all of your application's critical resources and order them from least precious to most precious. Design your code such that if a thread needs several resources, it requests them in order, starting with the least precious resource. Resources should be freed in the reverse order and as soon as it is possible. This is not a requirement to avoid deadlock, but it is good practice.

In the example given above, suppose that resource B is more precious than resource A. Here's how the code would resolve the situation:


 * Thread 2 already holds B, but because it wants A, it releases B and waits for A.
 * Thread 1 grabs B, then begins the task. It releases A when possible.
 * Thread 2 grabs A and waits for B.
 * Thread 1 finishes the task, then releases B.
 * Thread 2 grabs B, finishes the task, then releases A, then releases B.

The reason you should request the least precious resource first is that it doesn't matter as much if you hold it longer while waiting to acquire all the resources that you need. If the resource is precious, you want to hold it for the smallest amount of time possible, so other threads can use it.