for each client connection, such as in Figure 2-11. This program provides excellent performance,
simpler programming, and effortless scalability.
Figure 2-11. Different Clients Being Handled by Different Threads
System Resources
Programs that use two or more processes to access common data through shared memory are
effectively applying more than one thread of control. However, each such process must maintain a
complete process structure, including a full virtual memory space and kernel state. The cost of
creating and maintaining this large amount of state makes each process much more expensive, in
both time and space, than a thread. In addition, the inherent separation between processes may
require a major effort by the programmer to communicate among the different processes or to
synchronize their actions. By using threads for this communication instead of processes, the
program will be easier to debug and can run much faster.
An application can create hundreds or even thousands of threads, one for each synchronous task,
with only minor impact on system resources. Threads use a fraction of the system resources
needed by processes.
Distributed Objects
With the first releases of standardized distributed objects and object request brokers, your ability
to make use of these will become increasingly important. Distributed objects are inherently
multithreaded. Each time you request an object to perform some action, it executes that action in a
separate thread (Figure 2-12). Object servers are an absolutely fundamental element in distributed
object paradigm, and those servers are inherently multithreaded.
Figure 2-12. Distributed Objects Running on Distinct Threads
Search WWH :
