Debugging a multi threaded program
The following list points out few of the more frequent oversights and errors that can cause bugs in multithreaded programs.
1. Ephemeral a pointer to the caller's stack as an argument to a new thread.
2. Accessing global memory shared variable state without the protection of a synchronization mechanism.
3. Creating deadlocks originated by two threads trying to acquire rights to the same pair of global resources in alternate order so that one thread controls the first resource and the other controls the second resource and neither can proceed until the other gives up.
4. Trying to retain a lock already held (recursive deadlock).
5. Creating a hidden gap within synchronization protection. This is originated when a code segment protected by a synchronization mechanism contains a call to a function that frees and then reacquires the synchronization mechanism before it returns to the caller. The result is that it emerge to the caller that the global data has been protected when it actually has not.
6. Mixing UNIX signals with threads -- it is superior to use the sigwait() model for handling asynchronous signals.
7. Making extremely nested, recursive calls as well as using large automatic arrays can cause problems because multithreaded programs have a more limited stack size than single-threaded programs.
8. Identifying an inadequate stack size or using non-default stacks. And note that multithreaded programs particularly those containing bugs frequently behave differently in two successive runs, given identical inputs, for the reason that of differences in the thread scheduling order.
9. Generally multithreading bugs are statistical instead of deterministic. Tracing is typically a more effective method of finding order of execution problems than is breakpoint-based debugging.