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

最新推荐文章于 2026-01-31 11:00:00 发布

转载最新推荐文章于 2026-01-31 11:00:00 发布 · 455 阅读

本文深入探讨Linux线程的两大模型——核心级线程与用户级线程的区别，以及LinuxThreads与NPTL的优缺点对比。详细解释了如何确定GCC支持NPTL，并解析了LinuxThread作为核心级线程的特性。通过对比，阐述了NPTL在进程ID、信号处理等方面的优势改进。

有关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.
致命错误发送给线程组。