Linux multithreaded programming and Linux 2.6 under the NPTL

Linux multithreaded programming and Linux 2.6 under the NPTL

On Linux, from the kernel point of view, there is basically no difference between threads and processes-everyone is a process. Multiple threads of a process are just a few special processes they share the same code context, although they have their own process description structure. On Linux, such processes are called lightweight processes light weight process. This is the overall concept of threading, and we tend to start our multi-threaded programming journey with this concept in view. This is sufficient for getting started with multithreaded programming, but in fact threads are much more complex. First, the priority scheduling between multithreading, memory resource (stack) allocation and signal delivery is not simple to share the same process code context can be resolved. Second, the problem of efficiency: how to effectively use multi-CPU resources (2.4-core multithreading will not be able to use multiple CPUs, a process of threads are limited to the same CPU running). So the implementation of multi-line libraries Pthread is not a simple thing, it is built on a unique threading model.

in the Linux 2.4 kernel, a kernel thread is used in the Linux kernel to handle context switching (thread switching) of multiple threads in a user-state process.since there is no thread group concept in the kernel, that is, multiple threads of a process, you must rely on implementing an additional thread in the Pthread library to manage the establishment, exit, resource allocation and recycling, and thread switching of other user threads (that is, user program-generated threads). Because the hardware does not have a thread register, such as winter to support multi-threading, so the switching performance and low thread, and the need to introduce a complex mechanism in the process of the stack for each thread to separate the stack data location, and the switch to the stack data copy. The biggest problem is that there is a lack of support for the synchronization mechanism between threads in the kernel, so the Pthread library has to rely on signaling to achieve synchronization at the bottom, so the mutex operation and the condition volume operation in the thread mutex are converted to the signal operation of the process. The implementation of pthread is filled with extremely complex signal operations. We all know that the signal itself is a low-speed way of communication, so it is bound to slow down the actual performance of the thread. The final problem is signal processing, and because the kernel of the ignorance of the thread, must be managed by the thread to receive the signal after the delivery to the corresponding thread, on the one hand is inefficient, on the other hand due to the uncertainty of the signal (such as a sudden error reading a file), to accurately deliver all the signals to the correct thread is difficult to guarantee

In the IA-32 hardware structure, there is support for thread registers, so the thread context switching speed of pthread is greatly improved. However, due to limited hardware limitations, the number of threads must be less than 8,192, anyway, I think there are a lot of.

So starting from 2.5 code The Linux kernel uses the nptlnative Posix Thread Library) approach. NPTL's first draft of design ideas can be consulted nptl-design.pdf (http://people.redhat.com/drepper/nptl-design.pdf)

First of allany number of threads can be implemented on IA-32 and x86-64 bit architectures。 By introducing a TLS system call, you can create multiple GDT global descriptor tables, each of which maintains a descriptor table, each of which holds one thread.

second, the clone system call optimizes the thread's build and end functionality. It also eliminates the need for additional dispatch thread help to reclaim thread resources.

third, the signal delivery is done by the kernel, and no longer requires additional user configuration to manage the help of the thread, while the critical error signal ends the entire process.
its four, introduced a new exit system call Exit_group (). The original exit is reserved for exiting a single thread, and Exit_group is used to exit the entire process.
In its five, the new exec call ends with all threads in a process and then loads the execution of the new program, rather than just the thread of the call.
six, the resource usage of all threads (CPU resources, memory resources) is reported to the entire process and is no longer reported only to the initialization thread
Seven, the proc file system only displays information about the initialization thread, not all thread information (tens of thousands of threads will drag the proc file system to death)
its eight, which supports thread detachment, does not need to execute no wait for pthread_join threads.
Nine, the kernel maintains the initialization thread (which becomes the kernel thread), displays its state in the proc file system, and maintains the delivery of the signal until all threads exit.
its ten, the kernel supports unlimited number of threads.
Finally, Pthread_join is allowed to return after the child thread has died, that is, the return of Pthread_join and the state of the child thread becomes asynchronous, which improves performance.

According to the report, the NPTL thread start-up and abort time consumption is only about 1/8 of Linuxthread, when the number of threads increased sharply, the time difference is more obvious.
In the inter-thread synchronization experiment, the time consumption of frequent access to the critical area is only half the original.

More user test reports can be seenhttp://kerneltrap.org/node/422


As for how to use NPTL in development reference migrating to Linux Kernel 2.6 – part 5:migrating apps to the 2.6 kernel and NPTL (http://linuxdevices.com/articles/AT6753699732.html）。 There are so few things that need to be done.
1: System platform using the 2.6 kernel
2: Determine your GCC support NPTL
Use the # getconf gnu_libpthread_version command to see how the GCC supports multithreading at compile time
If the return is linuxthreads-0.10, your GCC does not support NPTL
If you return a message such as nptl-0.60, your GCC can be used to compile the new NPTL
3: Re-compiling your program in such a system environment, do not need to change the program in the Pthread call (but some functions are canceled)

Linux multithreaded programming and Linux 2.6 under the NPTL