Книга: Programming with POSIX® Threads
5.6.3 Many-to-few (two level)
5.6.3 Many-to-few (two level)
The many-to-few model tries to merge the advantages of both the many-to-one and one-to-one models, while avoiding their disadvantages. This model requires cooperation between the user-level Pthreads library and the kernel. They share scheduling responsibilities and may communicate information about the threads between each other.
When the Pthreads library needs to switch between two threads, it can do so directly, in user mode. The new Pthreads thread runs on the same kernel entity without intervention from the kernel. This gains the performance benefit of many-to-one implementations for the most common cases, when a thread blocks on a mutex or condition variable, and when a thread terminates.
When the kernel needs to block a thread, to wait for an I/O or other resource, it does so. The kernel may inform the Pthreads library, as in Digital UNIX 4.0, so that the library can preserve process concurrency by immediately scheduling a new Pthreads thread, somewhat like the original "scheduler activations" model proposed by the famous University of Washington research [Anderson, 1991]. Or. the kernel may simply block the kernel entity, in which case it may allow programmers to increase the number of kernel entities that are allocated to the process, as in Solaris 2.5 — otherwise the process could be stalled when all kernel entities have blocked, even though other user threads are ready to run.
Many-to-few implementations excel in most real-world applications, because in most applications, threads perform a mixture of CPU-bound and I/O-bound operations, and block both in I/O and in Pthreads synchronization. Most applications also create more threads than there are physical processors, either directly or because an application that creates a few threads also uses a parallel library that creates a few threads, and so forth.
Figure 5.7 shows the mapping of Pthreads threads (left column) to kernel entities (middle column) to physical processors (right column). In this case, the process has four Pthreads threads, labeled "Pthread 1" through "Pthread 4." The Pthreads library creates some number of kernel entities at initialization (and may create more later). Typically, the library will start with one kernel entity (labeled "kernel entity 1" and "kernel entity 2") for each physical processor. The kernel schedules these kernel entities (along with those from other processes) onto the
FIGURE 5.7 Many-to-few thread mapping
two physical processors, labeled "processor 1" and "processor 2." The important characteristics ofthis model are shown in Table 5.4.
Advantages | Disadvantages |
Can take advantage of multiprocessor hardware within a process. | More complicated than other models. |
Most context switches are in user mode (fast). | Programmers lose direct control over kernel entities, since the thread's priority may be meaningful only in user mode. |
Scales well; a process may use one kernel entity per physical processor, or "a few" more. | |
Little latency during system service blocking. |
TABLE 5.4 Many-to few thread scheduling
- 4 A few ways to use threads
- Part Two - Regulation By Code
- CHAPTER 14 Networking
- Installing Using a Network
- Network Configuration
- Configuring Wireless Networks
- Usenet Network Newsgroups
- System Services and Runlevels
- Runlevel Definitions
- Booting into the Default Runlevel
- Booting to a Nondefault Runlevel with GRUB
- Changing Runlevels