For some programs that benefit from concurrency, the decision whether to use
processes or threads can be difficult. Here are some guidelines to help you decide
which concurrency model best suits your program:
n All threads in a program must run the same executable. A child process, on the
other hand, may run a different executable by calling an execfunction.
n An errant thread can harm other threads in the same process because threads
share the same virtual memory space and other resources. For instance, a wild
memory write through an uninitialized pointer in one thread can corrupt
memory visible to another thread.
An errant process, on the other hand, cannot do so because each process has a
copy of the program’s memory space.
n Copying memory for a new process adds an additional performance overhead
relative to creating a new thread. However, the copy is performed only when
the memory is changed, so the penalty is minimal if the child process only reads
memory.
n Threads should be used for programs that need fine-grained parallelism. For
example, if a problem can be broken into multiple, nearly identical tasks, threads
may be a good choice. Processes should be used for programs that need coarser
parallelism.
n Sharing data among threads is trivial because threads share the same memory.
(However, great care must be taken to avoid race conditions, as described previ-ously.) Sharing data among processes requires the use of IPC mechanisms, as
described in Chapter 5.This can be more cumbersome but makes multiple
processes less likely to suffer from concurrency bugs.