linux 4.9 内核 nptl,【linuxThread和NPTL】

有关Linux线程的问题，有几个需要澄清的：

1.核心级线程与用户级线程

2.核内还是核外

3.linux的标准线程库是哪个？他们之间有什么区别？

4.lwp与线程的关系

5.LinuxThreads的缺点，NPTL作了哪些改善？

6.如何确定你的gcc支持NPTL

7.最后弱弱地问一句，linuxThread是核心级线程吗

以下是我的看法，不全

一.核心级线程与用户级线程

从进程演化出线程，最主要的目的就是更好的支持SMP以及减小(进程/进程)上下文切换开销。

针对线程模型的两大意义，分别开发出了核心级线程和用户级线程两种线程模型，分类的标准主要是线程的调度者在核内还是在核外。前者更利于并发使用多处理器的资源，而后者则更多考虑的是上下文切换开销。

二.核内还是核外

在线程机制的具体实现上，可以在操作系统内核上实现线程，也可以在核外实现。

核内实现的线程自然是核心级线程；

核外实现的线程可能是核心级线程，也可能是用户级；

例如：

在核外实现的线程可以分为"一对一"、"多对一"两种模型，前者用一个核心进程(也许是轻量进程)对应一个线程，将线程调度等同于进程调度，交给核心完成(所以，它是一个核心级线程)，而后者则完全在核外实现多线程，调度也在用户态完成(它是用户级线程)。

三.linux的标准线程库是哪个？他们之间有什么区别？

LinuxThreads、NGPT、NPTL

其中，LinuxThreads是2.5之前linux采用的标准thread库，NGPT为M:N模型，而NPTL是2.5以后的标准thread库，集成在glibc中。

四.lwp与线程的关系

在线程概念出现以前，为了减小进程切换的开销，操作系统设计者逐渐修正进程的概念，逐渐允许将进程所占有的资源从其主体剥离出来，允许某些进程共享一部分资源，例如文件、信号，数据内存，甚至代码，这就发展出轻量进程的概念。

Linux内核在 2.0.x版本就已经实现了轻量进程，应用程序可以通过一个统一的clone()系统调用接口，用不同的参数指定创建轻量进程还是普通进程。

针对LinuxThreads、NPTL：

它所实现的就是基于核心轻量级进程的"一对一"线程模型，一个线程实体对应一个核心轻量级进程，线程的调度等同于lwp的调度(核内调度，所以是核心级线程)，而线程之间的管理在核外函数库中实现。

五.LinuxThreads的缺点，NPTL作了哪些改善？

LinuxThread的缺点：

1.进程id问题

按照POSIX定义，同一进程的所有线程应该共享一个进程id和父进程id，但是目前"一对一"模型，导致每个线程都有自己的进程id

2.信号处理问题

由于异步信号是内核以进程为单位分发的，而LinuxThreads的每个线程对内核来说都是一个进程，且没有实现"线程组"，因此，某些语义不符合POSIX标准，比如没有实现向进程中所有线程发送信号

3.线程总数问题

4.管理线程问题

管理线程容易成为瓶颈，这是这种结构的通病；同时，管理线程又负责用户线程的清理工作，因此，尽管管理线程已经屏蔽了大部分的信号，但一旦管理线程死亡，用户线程就不得不手工清理了，而且用户线程并不知道管理线程的状态，之后的线程创建等请求将无人处理。

5.同步问题

LinuxThreads中的线程同步很大程度上是建立在信号基础上的，这种通过内核复杂的信号处理机制的同步方式，效率一直是个问题

NPTL：

1.进程id

引入thread group的概念，

Process ID-对每一个进程或者线程，都有一个独一无二的pid，

Thread Group ID-对于进程，TGID＝PID； 对于线程，TGID＝Parent PID;

TID-对每一个线程，都有一个独一无二的线程ID；

getpid－返回的是TGID；

通过这样一个方法，满足了进程id的要求

2.信号处理问题

见【附】

六.如何确定你的gcc支持NPTL

getconf GNU_LIBPTHREAD_VERSION命令来查看gcc的编译时的对多线程的支持方式

如果返回的是linuxthreads-0.10，说明你的gcc不支持NPTL

如果返回的是nptl-0.60这样的信息，说明你的gcc能用来编译新的NPTL

七.最后弱弱地问一句，linuxThread是核心级线程吗

当然是，不过它是在核外实现的，详见四

【附】

POSIX Signals and Multithreaded Applications

The POSIX 1003.1 standard has some stringent requirements for signal handling of multithreaded applications:

Signal handlers must be shared among all threads of a multithreaded application; however, each thread must have its own mask of pending and blocked signals.

信号处理函数在所有线程间共享，但每个线程自己可以设定信号掩码

The kill( ) and sigqueue( ) POSIX library functions must send signals to whole multithreaded applications, not to a specific thread. The same holds for all signals (such as SIGCHLD, SIGINT, or SIGQUIT) generated by the kernel.

kill和sigqueue函数传递的应该是TGID(线程组id)，接收者是该线程组中所有线程

Each signal sent to a multithreaded application will be delivered to just one thread, which is arbitrarily chosen by the kernel among the threads that are not blocking that signal.

送达线程组的信号应该只会被某一个线程接收，该线程由kernl从该线程组中未block该信号的所有线程中选定(arbitrarily)，记住，只有一个，所以，在一个线程组中，只能有一个定时器。

If a fatal signal is sent to a multithreaded application, the kernel will kill all threads of the applicationnot just the thread to which the signal has been delivered.

致命错误发送给线程组。