Improving Application Responsiveness

Any program in which many activities are not dependent upon each other can
be redesigned so that each independent activity is defined as a thread. For
example, the user of a multithreaded GUI does not have to wait
for one activity to complete before starting another activity.

Using Multiprocessors Efficiently

Typically, applications that express concurrency requirements with threads need not take into account
the number of available processors. The performance of the application improves transparently with
additional processors because the operating system takes care of scheduling threads for the
number of processors that are available. When multicore processors and multithreaded processors are available,
a multithreaded application's performance scales appropriately because the cores and threads are viewed
by the OS as processors.

Numerical algorithms and numerical applications with a high degree of parallelism, such as
matrix multiplications, can run much faster when implemented with threads on a multiprocessor.

Note - In this manual, whenever multiprocessors are discussed, the context applies also to multicore
and multithreaded processors unless noted otherwise.

Improving Program Structure

Many programs are more efficiently structured as multiple independent or semi-independent units of
execution instead of as a single, monolithic thread. For example, a non-threaded program
that performs many different tasks might need to devote much of its code
just to coordinating the tasks. When the tasks are programmed as threads, the
code can be simplified. Multithreaded programs, especially programs that provide service to multiple
concurrent users, can be more adaptive to variations in user demands than single-threaded programs.

Using Fewer System Resources

Programs that use two or more processes that access common data through shared
memory are applying more than one thread of control.

However, each process has a full address space and operating environment state. Cost
of creating and maintaining this large amount of state information makes each process
much more expensive than a thread in both time and space.

In addition, the inherent separation between processes can require a major effort by
the programmer. This effort includes handling communication between the threads in different processes,
or synchronizing their actions. When the threads are in the same process, communication
and synchronization becomes much easier.

Combining Threads and RPC

By combining threads and a remote procedure call (RPC) package, you can exploit
nonshared-memory multiprocessors, such as a collection of workstations. This combination distributes your application relatively
easily and treats the collection of workstations as a multiprocessor.

For example, one thread might create additional threads. Each of these children could
then place a remote procedure call, invoking a procedure on another workstation. Although
the original thread has merely created threads that are now running in parallel,
this parallelism involves other computers.

Note - The Message Processing Interface (MPI) might be a more effective approach to achieve
multithreading in applications that run across distributed systems. See http://www-unix.mcs.anl.gov/mpi/ for more information about
MPI.