Historically, debugger support for threads is rarely helpful for debugging threaded apps, regardless of the language.

Bugs in threaded apps can be roughly divided into two groups:

• Those that are bugs even without threading

  This group is by far the larger, incorporating all the types of bugs that can manifest in any program.

  The correct way to debug these is to disable the threading and ensure that the code performs correctly when it encounters each of the possible states that can arise once threaded.

  This sounds hard, but it consists of ensuring that each thread will do the correct thing for each combination of shared state it might encounter. The beauty of the ithreads paradigm is that the programmer has complete control over what is shared.

  1. So, to test your code, don't start the other thread.

     Manually set the shared state (shared variables) to each possible combination of values that might be in existance when a thread is run and ensure that it takes the correct action when that combination occurs.

  2. Then start the second thread, and have the first thread set the shared state to known values before falling into an indefinite sleep state.

     Ensure that the second thread does the correct thing for each combination.

  Rinse and repeat for all combinations of shared state.

  This may sound laborious, but in reality, you would find yourself having to do exactly the same steps via the debugger assuming it has a "suspend thread" facility, or manually if it does not.

  Unless your debugger can step backwards--which is almost impossible to provide in a threaded environment, and pretty meaningless in the non-determanistic of threads anyway. If you backstep, do you backstep one thread or all threads?--then trying to reach any particular point in your program in a known state will itself be very time consuming and laborious.

  And, having reached a particular point of interest; and witnessed what you think is the source of the bug; and corrected it; trying to re-run the corrected code back to the same place, with the same shared state, to verify the correction, is almost impossible.

  The keys to successful threaded code are:

  1. Share as little state as possible.
  2. Minimise the number of possible states--combinations of shared values.
  3. Use locking sparingly.
  4. Do not try to synchronised threads.

   

• Those that only occur as a result of threading. These are basically "timing problems".

  A threading debugger is almost completely useless for detecting and solving this type of problem as the very fact that you are single stepping one or more of the threads means that the random dynamics that create this type of problem, are extremely difficult to reproduce under the auspices of the debugger.

  The only notionally useful debugger facility in threaded code, is a 'watch' facility. The ability to have the debugger break out of the code, suspending *all* threads for inspection, when a particular combination of (shared) variable values occur. However, to provide this facility requires that the debugger itself perform so much locking and synchronisation, that the dynamic of the running program is never likely to be the same as when the debugger is not involved and therefore is unlikely to detect time dependant errors. Or if it does, they will be different from those that occur in non-debug runs.

The correct way to write threaded applications, is to treat each threads function as a separate program that when it runs, can find itself with a very limited set of states, and correctly deals with each of those possible states.