介绍NPTL （经典--诠释了线程的概念，以及linux调度单位）

POSIX Thread Library (NPTL)使Linux内核可以非常有效的运行使用POSIX线程标准写的程序。这里有一个测试数据，在32位机下，NPTL成功启动100000个线程只用了2秒，而不使用NPTL将需要大约15分钟左右的时间。

 

历史

在内核2.6以前的调度实体都是进程，内核并没有真正支持线程。它是能过一个系统调用clone()来实现的，这个调用创建了一份调用进程的拷贝，跟fork()不同的是,这份进程拷贝完全共享了调用进程的地址空间。LinuxThread就是通过这个系统调用来提供线程在内核级的支持的(许多以前的线程实现都完全是在用户态，内核根本不知道线程的存在)。非常不幸的是，这种方法有相当多的地方没有遵循POSIX标准，特别是在信号处理，调度，进程间通信原语等方面。

很显然，为了改进LinuxThread必须得到内核的支持，并且需要重写线程库。为了实现这个需求，开始有两个相互竞争的项目：IBM启动的NGTP(Next Generation POSIX Threads)项目，以及Redhat公司的NPTL。在2003年的年中，IBM放弃了NGTP，也就是大约那时，Redhat发布了最初的NPTL。

NPTL最开始在redhat linux 9里发布，现在从RHEL3起内核2.6起都支持NPTL，并且完全成了GNU C库的一部分。

 

设计

 

NPTL使用了跟LinuxThread相同的办法，在内核里面线程仍然被当作是一个进程，并且仍然使用了clone()系统调用(在NPTL库里调用)。但是，NPTL需要内核级的特殊支持来实现，比如需要挂起然后再唤醒线程的线程同步原语futex.

NPTL也是一个1*1的线程库，就是说，当你使用pthread_create()调用创建一个线程后，在内核里就相应创建了一个调度实体，在linux里就是一个新进程，这个方法最大可能的简化了线程的实现。

除NPTL的1*1模型外还有一个m*n模型，通常这种模型的用户线程数会比内核的调度实体多。在这种实现里，线程库本身必须去处理可能存在的调度，这样在线程库内部的上下文切换通常都会相当的快，因为它避免了系统调用转到内核态。然而这种模型增加了线程实现的复杂性,并可能出现诸如优先级反转的问题，此外，用户态的调度如何跟内核态的调度进行协调也是很难让人满意。

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/guosha/archive/2008/09/22/2960186.aspx

 

---------------------------------------------------------------------------

有一个问题一直没有想清楚，请教牛人，谢谢。
资源描述：
        系统环境：4个CPU, linux2.6内核，NPTL，SMP。
       
问题：
        (进程是资源单元；线程是执行单元。)
        一个进程拥有4个线程，这4个线程同时在4个CPU上运行。
        问1：系统的调度单位是进程还是线程呢？(针对linux2.6内核)；
        问2：如果调度单位是线程，每个线程都应该运行在同一个进程的上下文中，如果这样的话就需要对进程上下文加锁；同时如果有其他进程的线程也运行在同一个CPU上，那么进程的上下文切换会非常频繁？
             如果调度单位是进程，又没有办法解释同一个进程中的4个线程同时跑在4个CPU上？
        问3：看到一篇文章说“SMP的负载均衡是按进程数计算的”不知道是否正确。
             如果正确，同一个进程的所有线程应该分配到同一个CPU上，不解？

 

答：

问题1:     linux内核中的调度单位总是一个进程。但是内核中有对线程的支持。 问题2:     既然在linux的线程就是一个进程.就不存在什么所有线程都在同一进程上下文。而且这个观点是错误的。一个线程是什么？线程只是一个进程的子集。也就是说是一个进程上下文的子集。而且每个线程的上下文的很少有交集。除非两个线程之间需要通信。linux中进程所传建的线程本质就是进程。只不过这些子进程和父进程看到的都是同一地址空间，共享资源。 恢复一个线程的运行只需要恢复线程上下文。既然是线程在运行,何来进程上下文？ 线程的实现方式不同.但原理本质一样。 既然linux的调度单位是进程,而线程又是以进程实现的.所以进程的四个线程在4个CPU上同时运行是可能的.只要不存在互斥。 问题3:     这个是高级问题... 不清楚...楼主可以goolge下.应该很多文章和论文的。