"You can't do that- that's crazy!" These aren't words you hear everyday in the software development business. However, we heard those very words at TotalView Technologies from a participant in a recent training session after a demonstration of the TotalView Debugger's thread width breakpoint.

In the demonstration, thread width breakpoints were set on a line of code that was about to be executed by some threads, but not by others. Next, we continued to run all of the threads in the application. As the participants watched, TotalView reflected that all threads were running and then a few moments later, several of the threads popped into the "at breakpoint" status, while the remaining threads continued to run.

Then the objection came: "You can't do that." The participant explained that he'd done multi-threaded debugging in several different situations, on platforms ranging from Windows to IRIX to Linux, and that everywhere it was the same. When the process hits a breakpoint on a line of code, even in a multi-threaded application, all threads stop and the debugger prompts you for input.

The TotalView Debugger does things differently. TotalView has a fully asynchronous interface and supports asynchronous thread control.

TotalView's asynchronous interface (both in the Graphical Interface as well as in the Command Line Interface) gives the debugger the ability to take commands from the user at the same time that it is receiving updates from the processes that are being debugged.

This gives the user the ability to interact smoothly and clearly with both the debugger and the program.

With TotalView's asynchronous thread control, the process can be stopped at any time and any subset of the threads can be put back into the running state. One thread can be run while the others are all stopped, or one thread can be held while the others are all given the chance to run. The user can test scenarios that might reveal a multi-threaded bug and either prove or disprove each hypothesis.