Linux multi-thread programming and NPTL under Linux2.6

Linux multi-threaded programming and NPTL under Linux2.6-general Linux technology-Linux programming and kernel information. The following is a detailed description. Author: nathanxu

Due to work needs in the past few days, I have considered the multi-thread related information in Linux. In Linux, the most common multi-thread support library is the Pthread library, which is part of the glibc library. However, there are very few documents about Pthread, especially the introduction of POSIX multithreading specifications and the introduction of multithreading implementation methods in the pthread library. Multi-threaded programming is a technology that must be mastered by system programmers, so it always makes the programmers in learning feel a headache. I don't have much experience in multi-threaded programming. Here I just collect some new information about multithreading on Linux to facilitate mutual learning and exchange.

Here, by the way, there is a book on the market that introduces multithreading, Posix multi-thread Programming, which is a Chinese translation of Programming with POSIX Muiltthread, this is the only topic I can find six months ago to introduce multi-threaded programming. I personally feel that the content of one of the first 1/3 in this book is still good, but the content behind it is very obscure and there are many obvious text errors. There are several translators looking at this book. It is estimated that the different translation capabilities of each person lead to the beginning and end of this book. Therefore, I do not recommend that you buy this book as a Bible collection. The content of the first half of this book focuses on the Posix multithreading. The most exciting introduction is several multi-threaded programming models. We recommend that you read the multi-threaded mutex and synchronization mechanisms. These contents are not the first in this book. as early as the second volume of "UNIX network programming", inter-process communication had these classic introductions, however, the ability to systematically integrate these mechanisms into multi-threaded programming is still commendable. After all, the two volumes of UNIX network programming are too old and the books are too thick. They are not what most programmers can sit down and read carefully. Here, I also want to express my criticism for Microsoft's technical shortcomings. In the platform sdk section of msdn, the content of windows multi-thread programming is really simple and ridiculous. There are only silly functions to establish and exit the thread, and there is no introduction to mutex and conditions. You can only find it in its sample code. The thread synchronization method in the sample code is actually an endless loop, I don't know what it means to sell windows for so much money. The multi-thread encapsulation in MFC seems like this, but I cannot imagine how Microsoft implements the thread function on MFC on such a simple system api. Those who support windows should not drop eggs here. It is best to write an introduction to multithreading on windows. This is more meaningful than hitting an egg. All right, the book goes on to talk about multithreading on Linux.

In Linux, from the kernel perspective, there is basically no difference between threads and processes-everyone is a process. Multiple Threads of a process are only special processes. Although they have their own process description structure, they share the same code context. In Linux, such a process is called a Lightweight process Light weight process. This is the general concept of threads. We often start our multi-threaded programming journey with an understanding of this concept. This is enough for multi-threaded programming, but in fact the thread is much more complicated. First of all, priority scheduling between multiple threads. Memory Resource (stack) allocation and signal delivery are not something that can be solved simply by sharing the context of the same process code. Second, the efficiency problem: how to effectively use multiple cpu resources (2.4 of the multi-thread kernel won't be able to use multiple CPUs, And the threads of a process are limited to run on the same cpu ). Therefore, the implementation of the multi-threaded library Pthread is not a simple task. It is built on the unique thread model.

In the Linux 2.4 kernel, a kernel thread is used in the Linux kernel to process context switching (thread switching) of multiple threads in the user State process ). Because there is no thread group concept in the kernel, that is, multiple threads of a process, therefore, an additional thread must be implemented in the pthread library to manage the creation, exit, resource allocation and collection, and thread switching of other user threads (that is, the thread generated by the user program. At that time, the hardware did not support multithreading in winter and winter such as thread registers, so thread switching performance was low, in addition, it is necessary to introduce a complex mechanism to divide the stack data location for each thread in the process stack, and copy stack data during switchover. The biggest problem is the lack of support for inter-thread synchronization mechanisms in the kernel. Therefore, the pthread library has to rely on the signal method at the underlying layer for synchronization, therefore, the mutex operations and conditional operations in the thread mutex are converted to the signal operations of the process. The implementation of pthread is full of extremely complex signal operations. As we all know, the signal itself is a low-speed communication method, so it is bound to slow down the actual performance of the thread. The last problem is signal processing. Due to the kernel's ignorance of the thread, the management thread must receive the signal and deliver it to the corresponding thread. On the one hand, the efficiency is low, on the other hand, due to the uncertainty of the signal generation (such as a sudden error when reading a file), it is difficult to accurately deliver all signals to the correct thread.

In the hardware structure of the IA-32, the support for the thread Register appears, so the thread context switching speed of Pthread is greatly improved. However, due to hardware restrictions, the number of threads Must be smaller than 8192. I think there are already many threads.

Since code 2.5, the Linux kernel adopts the NPTLNative Posix Thread Library method. Nptldesign concepts for reference nptl-design.pdf (http://people.redhat.com/drepper/nptl-design.pdf)

First, we can implement any number of threads in the IA-32 and x86-64 bit architecture. By introducing TLS system calls, you can create multiple GDT Global Descriptor tables. Each cpu maintains one Descriptor Table and each table item stores one thread.

Second, the clone system call optimizes the thread creation and termination functions. The thread resources can be recycled without the help of Additional scheduling threads.

Third, signal delivery is completed by the kernel, without the help of additional user State management threads, and the entire process ends between serious error signals.
4. introduces a new exit system call exit_group (). The original exit retained is used to exit a single thread, and exit_group is used to exit the entire process.
Fifth, the new exec call will end to all threads in a process before loading the execution of the new program, rather than simply ending the call thread.
6th, the resource usage (cpu resources, memory resources) of all threads will be reported to the entire process, rather than only to the initialization thread.
7. The proc file system only displays the information of the initialization thread, instead of the information of all threads (tens of thousands of threads will drag the proc file system to death)
8. Thread disconnection is supported. The thread executing Pthread_join does not need to execute no wait.
9. The initialization thread (changed to the kernel thread) is maintained by the kernel, and its status is displayed in the proc file system. Maintenance is performed until all threads exit to ensure signal delivery.
10. The number of threads supported by the kernel is unlimited.
Finally, pthread_join is allowed to return after the sub-thread is dead, that is, the return of pthread_join and the sub-thread state change to asynchronous, improving performance.

According to the report, the startup and suspension time of NPTL threads only consume about 1/8 of Linuxthread. When the number of threads increases rapidly, the time consumption difference is more obvious.
In the inter-thread synchronization test, the time consumption for frequent entry and exit in the critical section is only half of the original time consumption.

More user test reports can be viewed in http://kerneltrap.org/node/422


For how to use NPTL in development, refer to 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 several things to do.
1: System Platform with 2.6 kernel
2: Are you sure your gcc supports NPTL
Run the # getconf GNU_LIBPTHREAD_VERSION command to check the multi-thread support mode during gcc compilation.
If the return is a linuxthreads-0.10, your gcc does not support NPTL
If the returned information is such a nptl-0.60, it means your gcc can be used to compile the new NPTL
3: Re-compile your program in such a system environment. You do not need to change the call to pthread in the Program (but some functions are canceled)