DeadlockDetection Requirements

As you might have noticed in the preceding tips and tricks section, I didn't provide very many suggestions about what to do when an unexpected deadlock paralyzes your code. Most of the recommendations there were more preventive measures you can take to try to avoid deadlocks in the first place rather than prescriptions for fixing them when they do occur. As you know, solving deadlocks with just the debugger isn't easy. In this section, you'll get the additional help you need, in the DeadlockDetection utility.

Here's the list of basic requirements I worked with when I developed DeadlockDetection:

1. Show exactly where the deadlock happens in the user's code. A tool that tells only that EnterCriticalSection is blocked doesn't help much. To be really effective, the tool needs to let you get back to the address, and consequently the source file and line number, where the deadlock occurred so that you can fix it quickly.

2. Show which synchronization object caused the deadlock.

3. Show which Windows function is blocked and the parameters passed to the function. It helps to see timeout values and the values passed to the function.

4. Determine which thread caused the deadlock.

5. The utility must be lightweight so that it interferes with the user's program as little as possible.

6. The information output processing must be extensible. The information collected in a deadlock detection system can be processed in many ways, and the utility needs to allow others, not just you, to extend the information as they see fit.

7. The tool must integrate easily with the user's programs.

One of the key points to keep in mind with a utility such as DeadlockDetection is that it definitely affects the behavior of the application it's observing. Once again, it's the Heisenberg uncertainty principle in action. DeadlockDetection can produce deadlocks in your programs you might not otherwise see because the work it does to gather information slows down your threads. I almost defined this behavior as a feature because any time you can cause a deadlock in your code, you've identified a bug, which is the first step toward correcting it—and as always, it's better for you to find the bugs than for your customers to find them.