Shulou(Shulou.com)06/01 Report--

This article shows you how to analyze linux threads, the content is concise and easy to understand, it will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

In many classic operating system textbooks, the process is always defined as the execution instance of the program, which does not execute anything, but all kinds of resources needed to maintain the application. The thread is the real execution entity. In order for a process to do some work, the process must contain at least one thread.

The process maintains the resources (static resources) contained in the program, such as address space, set of open file handles, file system status, signal processing handler, etc., and run-related resources (dynamic resources) maintained by threads, such as run stack, scheduling related control information, signal sets to be processed, etc.

However, there has always been no concept of threads in the linux kernel. Each execution entity is a task_struct structure, often referred to as a process. A process is an execution unit that maintains dynamic resources related to execution. At the same time, it refers to the static resources needed by the program (note that we are talking about processes in linux). When creating a child process by calling clone, the child process can selectively share the resources referenced by the parent process. Such child processes are often called lightweight processes.

Threads on linux are based on lightweight processes and are implemented by user-mode pthread libraries. After using pthread, from the user's point of view, each task_struct corresponds to a thread, and a group of threads and their common reference resources are a process.

However, a set of threads does not just refer to the same set of resources, they must also be considered as a whole. In this regard, the POSIX standard puts forward the following requirements:

(1) when viewing the process list, the relevant set of task_struct should be presented as a node in the list.

(2) the signal sent to the "process" (corresponding to the kill system call) will be shared by the corresponding set of task_struct and processed by any of the "threads"

(3) the signal sent to a "thread" (corresponding to pthread_kill) will only be received by the corresponding task_struct and will be processed by itself.

(4) when the "process" is stopped or continued (corresponding to the SIGSTOP/SIGCONT signal), the corresponding set of task_struct states will change.

(5) when a "process" receives a fatal signal (such as a SIGSEGV signal due to a segment error), the corresponding set of task_struct will all exit.

(6) and so on (the above may not be enough)

1. Linuxthreads

Before linux 2. 6, the corresponding implementation of the pthread library was a lib called linuxthreads. Linuxthreads uses the previously mentioned lightweight processes to implement threads, but for those requirements made by POSIX, linuxthreads does not implement (in fact, powerless) except for point 5:

(1) if program A runs and program A creates 10 threads, you will see 11 A processes instead of 1 when executing the ps command under shell (note, not 10, which will be explained below)

(2) whether it is kill or pthread_kill, the signal can only be received by a corresponding thread.

(3) the SIGSTOP/SIGCONT signal works on only one thread.

Fortunately, linuxthreads achieved point 5, which I think is the most important. If a thread hangs, the whole process is still running as if nothing had happened, and there may be a lot of inconsistencies. The process will not be a whole, and the thread cannot be called a thread. Perhaps this is why linuxthreads can exist and has been used for several years, although it is a far cry from the requirements of POSIX. However, linuxthreads still paid a lot of price to achieve this "point 5" and created a big performance bottleneck of linuxthreads itself.

Let's talk about why program A creates 10 threads, but there are 11 A processes in ps. Because linuxthreads automatically creates a management thread. The "point 5" mentioned above is achieved by managing threads. When the program starts running, there is no administrative thread (because although the program is linked to the pthread library, it may not use multithreading). When the program called pthread_create for * times, linuxthreads found that the management thread did not exist and created the management thread. This administrative thread is the son of * threads (main threads) in the process. Then in pthread_create, a command is sent to the administrative thread via pipe, telling it to create the thread. That is to say, all threads except the main thread are created by the management thread, which is their father. Therefore, when any child thread exits, the administrative thread will receive a SIGUSER1 signal (this is specified when the child thread is created through clone). The administrative thread determines whether the child thread exits normally in the corresponding sig_handler, if not, kills all threads and then commits suicide. So, what about the main thread? The main thread is the parent of the administrative thread and does not signal the administrative thread when it exits. Therefore, in the main loop of the administrative thread, check the ID number of the parent process through getppid. If the ID number is 1, the father has quit and hosted himself to the init process (process 1). At this point, the administrative thread will also kill all child threads and then commit suicide. So, what if the main thread exited actively by calling pthread_exit? According to posix standards, other child threads should continue to run in this case. Therefore, in linuxthreads, the main thread will not really exit after calling pthread_exit, but will block in the pthread_exit function and wait for all child threads to exit before pthread_exit will let the main thread exit. In the process of this, etc., the main thread has been sleeping.

It can be seen that thread creation and destruction are accomplished by managing threads, so managing threads has become a performance bottleneck of linuxthreads. Creation and destruction require an inter-process communication, a context switch before it can be executed by the management thread, and multiple requests are executed sequentially by the management thread.

2. NPTL

By linux 2.6, glibc has a new pthread library-- NPTL (Native POSIX Threading Library). NPTL implements all the five requirements of POSIX mentioned earlier. However, in fact, it is not so much implemented by NPTL as implemented by the linux kernel.

In linux 2.6, the kernel has the concept of thread group, and a tgid (thread group id) field has been added to the task_struct structure. If the task is a main thread, its tgid is equal to pid, otherwise tgid is equal to the pid of the process (that is, the pid of the main thread). In the clone system call, passing the CLONE_THREAD parameter sets the tgid of the new process to the tgid of the parent process (otherwise the tgid of the new process will be set to its own pid).

There are two similar XXid in task_struct: task- > signal- > pgid saves the pid of the leading process of the process group, and task- > signal- > session saves the pid of the session leading process. Process groups and sessions are associated with these two id.

With tgid, the kernel or related shell programs know whether a tast_struct represents a process or a thread, and when to show them and when not to show them (for example, threads don't show them in ps).

The getpid (get process ID) system call also returns the tgid in tast_struct, while the pid in tast_struct is returned by the gettid system call.

There are also some problems with not displaying child threads when executing ps commands. For example, when the program a.out runs, a thread is created. Suppose the pid of the main thread is 10001 and the child thread is 10002 (both have a tgid of 10001). At this point, if you kill 10002, you can kill the 10001 and 10002 threads together, even though you can't see the 10002 process when you execute the ps command. If you don't know the story behind the Linux thread, you will feel that you have encountered a psychic event.

We can do the following verification, and the program segment test.cpp is as follows:

# include

# include

# include

# include

Using namespace std; void* doit (void*); int main (void) {pthread_t tid; pthread_create (& tid,NULL,doit,NULL); pause (); / / the main thread hangs (otherwise the main thread terminates, the child thread dies)} void* doit (void* agr) {printf ("thread is created!\ n"); pause (); / / suspend thread}

The program hangs after creating a thread, and the child thread is outputting "thread is created!" Hang up, too. The running result is shown in figure 1.

Figure 1

After looking at the process pid, we found that the pid of a.out is 23130. We use kill to terminate the process with a pid of 23131 (note that there is no such process in ps), as shown in figure 2.

Figure 2

But it turns out that the a.out process is also terminated, as shown in figure 3. The reason is that 23131 is the pid of the created thread. If the thread terminates abnormally, the process terminates.

Figure 3

In order to cope with "signals to processes" and "signals to threads", task_struct maintains two sets of signal_pending, one shared by thread groups and the other unique to threads. The signal sent through kill is placed in the signal_pending shared by the thread group and can be processed by any thread. The signal sent through pthread_kill (pthread_kill is the interface of pthread library and tkill in the corresponding system call) is placed in the thread's unique signal_pending and can only be processed by this thread. When a thread stops / continues, or receives a fatal signal, the kernel applies processing action to the entire thread group.

3. NGPT

Speaking of which, I would also like to mention NGPT (Next Generation POSIX Threads). Both of the above-mentioned thread libraries use kernel-level threads (each thread corresponds to a scheduling entity in the kernel), which is called the 1:1 model (1 thread corresponds to 1 kernel-level thread), while NGPT intends to implement the MRV N model (M threads correspond to N kernel-level threads), which means that several threads may be implemented on the same execution entity.

The thread library needs to abstract several execution entities from the execution entities provided by a kernel and implement the scheduling between them. This abstracted execution entity is called a user-level thread. In general, this can be done by assigning a stack to each user-level thread and then context switching through longjmp. Just click "setjmp/longjmp" from Baidu and you will know. But there are actually a lot of details to deal with. The current NGPT does not seem to achieve all the expected functions, and is not ready to do so for the time being.

The switching of user-level threads is obviously faster than that of kernel-level threads, the former may be a simple long jump, while the latter needs to save / load registers, enter and then exit kernel state. (process switching also needs to switch address space, etc.) On the other hand, user-level threads can not enjoy multiprocessors, because multiple user-level threads correspond to a kernel-level thread, and a kernel-level thread can only run on one processor at a time.

However, after all, the thread model of MVR N provides a means for threads that do not need parallel execution to run on several user-level threads corresponding to a kernel-level thread, which can save their switching overhead. It is said that some UNIX-like systems (such as Solaris) have implemented a relatively mature M: n threading model, and its performance is better than that of linux threads.

The above is how to analyze linux threads. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.