Multithreaded user-level threading and kernel-level threading from C + + multicore advanced Programming

Go http://book.51cto.com/art/201006/206946.htm 6.1.1 User-level thread and kernel-level thread 2010-06-21 20:37 qining/Dong Zehui translation Tsinghua University Pressfont Size:T | T

"C + + multicore Advanced Programming", chapter 6th Multi-Threading, this chapter describes: what is a thread; Pthread API for thread management, thread scheduling and prioritization, thread contention scope, extended thread_object to encapsulate threading properties functionality. This section introduces user-level threading and kernel-level threading.

AD:

6.1.1 User-level threads and kernel-level threads

There are 3 implementation models of threads:

User-or application-level threads

Kernel-level threading

User-and kernel-level hybrid threads

Figure 6-1 shows the 3 threading implementation models. Figure 6-1 (a) shows the user-level thread, figure 6-1 (b) shows the kernel-level thread, and figure 6-1 (c) shows the mix of the user thread and the kernel thread.

(Click to view larger image) (a) User-level threading

(Click to view larger image) (b) kernel-level threading Figure 6-1

(Click to view larger image) (c) Mixed threads Figure 6-1 (cont.)

One of the big differences between these implementations is the ability of their schemas and the threads to be assigned to the processor. These threads run in user mode or in kernel mode.

In user mode, a process or thread is an instruction in an executing program or a link library, and they do not make any calls to the operating system kernel.

In kernel mode, a process or thread is making a system call, such as accessing a resource or throwing an exception. Also, in kernel mode, a process or thread can access objects defined in kernel space.

User-level threads reside in user space or mode. The run-time library manages these threads, which are also in user space. They are not visible to the operating system and therefore cannot be dispatched to the processor core. Each thread does not have its own thread context. Therefore, in the case of simultaneous execution of threads, each process can only have one thread running at any given moment, and only one processor core will be assigned to that process. There may be thousands of user-level threads for a process, but they have no effect on system resources. The run-time library dispatches and dispatches these threads. As seen in Figure 6-1 (a), the library scheduler selects a thread from multiple threads in the process and then associates the thread with one of the kernel threads allowed by the process. The kernel thread will be assigned to the processor core by the operating system scheduler. A user-level thread is a "many-to-one" thread mapping.

Kernel-level threads reside in kernel space, which are kernel objects. With kernel threads, each user thread is mapped or bound to a kernel thread. The user thread is bound to the kernel thread for its lifetime. Once the user thread terminates, two threads will leave the system. This is referred to as a "one-to-one" thread mapping, as shown in 6-1 (b). The operating system scheduler manages, dispatches, and dispatches these threads. The runtime library requests a kernel-level thread for each user-level thread. The memory management and scheduling subsystem of the operating system must take into account the large number of user-level threads. You must know what the maximum number of threads per process is allowed. The operating system creates a context for each thread. The context of the thread is described later in this chapter. Each thread of a process can be assigned to the processor core when the resource is available.

A hybrid thread implementation is a cross between a user thread and a kernel thread, allowing both the library and the operating system to manage threads. User threads are managed by the runtime Library scheduler, and kernel threads are managed by the operating system scheduler. In this implementation, the process has its own kernel thread pool. A running user thread is dispatched by the run-time library and marked as an available thread ready for execution. The operating system selects a user thread and maps it to an available kernel thread in the thread pool. Multiple user threads can be assigned to the same kernel thread. In Figure 6-1 (c), process A has two kernel threads in its thread pool, while process B has 3 kernel threads. User Threads 2 and 3 of process A are mapped to kernel threads (2). Process B has 5 threads, user threads 1 and 2 are mapped to the same kernel thread (3), User threads 4 and 5 are mapped to the kernel with the same kernel thread (5). When you create a new user thread, you simply map it to one of the existing kernel threads in the thread pool. This implementation uses a "many-to-many" thread mapping. Try to use many-to-one mappings in this method. Many user threads will be mapped to a kernel thread, as you can see in the previous example. Therefore, the request to the kernel thread will be less than the number of user threads.

The kernel thread pool is not destroyed and rebuilt, and these threads are always on the system. They are assigned to different user-level threads when necessary, rather than creating a new kernel thread when a new user-level thread is created, and a new kernel thread is created when a pure kernel-level thread is created. The context is created only for each thread in the pool. With kernel threads and mixed threads, the operating system allocates a set of processor cores, and the threads of the process can run on top of those processor cores. Threads can only run on the processor core assigned to the thread they belong to.

User-level threading and kernel-level threading become important when determining the scheduling model and the scope of contention for a thread. The scope of the competition determines the use of the specified thread against those threads competing with the processor, and is important for the operating system's memory management of a large number of threads.