Figure 1.1 shows us Single-threaded and multithreaded processes.
A word processor may have a thread for showing graphics, another thread for responding to keystrokes to the user, and a third thread for performing spelling and grammar checking in the background. In certain situations, a single application may be required to perform several same tasks. For example, a Web server accepts client requests to the Web pages, images, sound, and so forth. A busy Web server may have several (perhaps thousands of) clients concurrent access it. If the Web server ran a traditional single-threaded process, it would capable to service only one client at a time, art a client might have to wait a very long time for its request to be serviced. One solution is to have the server run as a single process that receives requests. Then server accepts a request, it creates a different process to service to request. In fact, this process-creation method was in common use before threads became popular. Process creation is time consuming and resource intensive, however. If the new process will perform the same tasks as the already existing process, why incur all that overhead? It is generally more efficient to use one process that contains multiple threads. If the Web-server process is multithreaded, the server will create an each one thread that listens for client requests. the server will create a new thread to service the request and resume listening for additional requests. This is illustrated in Figure 1.2.
Threads also play a vital role in remote procedure call (RPC) systems. Recall from that RPCs allow interposes communication by providing a communication mechanism similar to ordinary function calls. Typically, RPC servers are multithreaded. When a server accept a message, it services the message using a separate thread. This allows the server to service several concurrent requests. Finally, most operating system kernels are now multithreaded; several threads operate in the kernel, and each thread performs a different task,
Figure 1.2 Multithreaded server architecture.
Such as managing devices or interrupt handling. For example Solaris creates a set of threads in the kernel specifically for interrupt handling; Linux uses a kernel thread for managing the amount of free memory in the system.1.2 Benefits The benefits of multithreaded programming can be broken down into four major categories. Multithreading an interactive application may allow a program to continue running even if part of it is blocked or is performing a complex operation, thereby increasing responsible to the user. For Instance a multiple thread Web browser could allow user interaction in one thread while an image was being loaded in another thread. Resource sharing. Processes may only share resources through techniques such as shared memory or message passing. Such techniques must be explicitly arranged by the programmer. However, threads share the memory and the resources of the process to which they by default. The benefit of sharing code and data is that it allows an application to have several different threads of activity within the same address space.3. Economy. Allocating memory and resources for process creation is costly.
Because threads share the resources of the process to threads. Empirically gauging the difference in overhead can be difficult, but in general it is time consuming to create and manage processes thread. In Solaris for example, creating a process is about thirty times slower than is creating a thread. Scalability. The benefits of Multithreading can be greatly increased in a multiprocessor architecture, where threads may be running same on different processors. Process which is single-threaded can be only run on processor, regardless how many are available. Multithreading on a multiCPU machine increases parallelism.
Our discussion so far has treated threads in a generic sense. However, support for threads provided either at the user level, for or by the kernel, for threads. User threads are supported above the kernel and are managed without kernel support, and kernel threads are supported and managed directly by the o.s virtually all contemporary operating systems-including Windows XP, Linux, Mac OS X, Solaris, and Tru64 UNIX (formerly Digital UNIX)-support kernel threads. Ultimately, a relationship must exist between user threads..
1.2.1 Many-to-One Model
The many-to-one model (Figure 1.3) maps many user-level threads to one kernel thread. Thread management is the thread library in user
Figure 1.3 Many-to-one model.
Figure 1.4 One-to-one models.
Space, so it is efficient; but the entire process will block if a thread makes a blocking system call. Also, because one thread can access the kernel at a time, multiple threads are unable to nm in parallel on multiprocessors. a thread library available for Solaris-uses this model as does GNU.
1.2.2 One-to-One Model
The one-to-one model (Figure 1.4) maps each user thread to a kernel thread. It provides the many-to-one model by allowing another thread to run when a thread makes a blocking system call it also allows multiple threads to run in parallel on multiprocessors. The drawback to this model is that creating a user thread requires creating the corresponding kernel thread. Because the overhead of creating threads can burden the performance of an application, implementations of the same model restrict the number of threads supported by the system. Linux, along with the family of Windows operating systems, implement the one-to-one model.
1.2.3 Many-to-Many Model
The many-to-many model (Figure 1.5) multiplexes many user-level threads to a smaller or equal number of kernel threads. Count of kernel threads may be specific to either a particular application or a particular machine (an application may be allocated more kernel threads on a multiprocessor than on a uni processor). Whereas the many-to-one model allows the developer to
Figure 1.5 Many-to-many model.
Figure 1.6 Two-level models.
Create as many user threads as she wishes; true concurrency is not gained because the kernel can schedule only one thread at a time. The one-to-one model allows for greater concurrency, The many-to-many model
Suffers from neither of these shortcomings: developers can create as many user threads as a necessary, to the corresponding kernel threads can run in parallel on a multiprocessor. Also, when a thread act as a blocking system call, the kernel can process thread for execution. One popular variation on the many-to-many model still multiplexes many user-level threads to a smaller or equal number of kernel threads but also allows a user-level thread to be bound to a kernel thread. This variation, sometimes referred to as the two-level model (Figure 1.6), is supported by operating systems such as IRlX, HP-UX, and Tru64 UNIX. The Solaris operating system supported the two-level model in versions older than Solaris 9. However, beginning with Solaris 9, this system uses the one-to-one model.