监控C＃线程 - 哪个/什么时候做什么

Question

As everybody, I am used to debugging my code in VS in step-by-step mode. Well, now that I have an application with many Background Workers everywhere, I am not in Kansas anymore.

What is the most efficient way to debug threaded applications and be able to monitor each and every thread to keep track of what's happening all over the code?

As of now, I stick to good ol' debugging using separate logger instances for each Thread, but this is slowly becoming a nightmare and I'll soon be drowning into my own logs.

Answer 1

Don't try to debug everything all at once. Narrow your focus to a particular behavior in one thread or pair of threads that interact around some mutex lock. If accessing a shared resource is the problem, set breakpoints around use of that resource (which should be in common code, not all over the place).

If you just want to see that thread 3 completed before thread 1, or that thread 2 used up all its work items and is sitting idle, use logs for that.

You can also use the VS Threads view to see what each thread is doing whenever the process is stopped at any breakpoint on any thread. This can give you some insight into what all the threads are doing at any given instant.

Answer 2

A small tip that might ease your pain is to use Visual Studio to freeze threads that you are not interested in. Then when you tell the debugger to continue, the frozen threads will never execute and will not hit breakpoints and confuse you.

Maybe you can use this method to allow only the threads you are debugging to work. Eg keep one thread that enqueues and one thread that dequeues active, but freeze everything else.

You can freeze/thaw threads from Visual Studio's Threads window, by right-clicking on a thread.

Answer 3

Write it correctly the first time.

Joking aside, the trick to debugging is to break it down into manageable parts. Tackle one worker task at a time, make absolutely sure it does what it's supposed to.

Once you've done that, debugging issues in the main thread is a lot easier, because you can pretty much ignore the background workers and just presume they're yielding correct results when they should be.

The only place left that's harder to debug than a single-threaded application is the interconnect between the threads, which shouldn't be much more difficult if you're using the libraries the way you should be.

Answer 4

I Stumbled upon a detailed MSDN article about Debugging Multithreaded Applications wich was of great help. Thanx for all the previous answers that guided me towards the right track.