When you design and code a multithreaded program, consider the following problems and accommodate or eliminate each problem as appropriate:
· Potential Complexity
The level of expertise required for designing, coding, and maintaining multithreaded programs may be higher than for most single-threaded programs because multithreaded programs may need shared access to resources, mutexes, and condition variables. Weigh the potential benefits against the complexity and its associated risks.
· Nonreentrant Software
If a thread calls a routine or library that is not reentrant, use the global locking mechanism to prevent the nonreentrant routines from modifying a variable that another thread modifies. Programming with Threads discusses nonreentrant software in more detail.
Note: A multithreaded program must be reentrant; that is, it must allow multiple threads to execute at the same time. Therefore, be sure that your compiler generates reentrant code before you do any design or coding work for multithreading. (Many C, Ada, Pascal, and BLISS compilers generate reentrant code by default.)
If your program is nonreentrant, any thread synchronization techniques that you use are not guaranteed to be effective.
· Priority Inversion
Priority inversion prevents high-priority threads from executing when interdependencies exist among three or more threads. Programming with Threads discusses priority inversion in more detail.
· Race Conditions
A type of programming error called a race condition causes unpredictable and erroneous program behavior. The DCE Backing Store discusses race conditions in more detail.
· Deadlocks
A type of programming error called a deadlock causes two or more threads to be blocked from executing. Programming with Threads discusses deadlocks in more detail.
· Blocking Calls
Certain system or library calls may cause an entire process to block while waiting for the call to complete, thus causing all other threads to stop executing. Programming with Threads discusses blocking in more detail.