http://blog.csdn.net/adcxf/archive/2009/02/26/3940982.aspx
NPTL
在Linux操作系统中，本地POSIX线程库（NPTL）是一种软件特性，它可让Linux的内核 ，高效地运行那些使用POSIX风格的线程所编写的程序。
测试中，NPTL在一个IA-32处理器上，成功地同时跑了10万个线程，启动这些线程只用了不到2秒。比较起来，在不支持NPTL的内核上，这个测试花费了大约15分钟。
以前（也就是在2.6内核以前），Linux把进程当作其调度实体 ，内核并不真正支持线程。可是，它提供了一个clone()系统调用 ——创建一个调用进程的拷贝 ，这个拷贝与调用者共享地址空间。LinuxThreads项目就是利用这个系统调用，完全在用户级模拟了线程；不幸的是，它与真正的POSIX标准在一致性上面存在大量的问题，在信号处理，任务调度，以及进程间同步原语 方面尤为突出。
要改进LinuxThreads，显然需要一些内核方面的支持，并从写线程库。针对于这一需求的两个竞争项目启动了——NGPT，或称下一代POSIX线程，由包括来自IBM的开发者在内的一个团队进行开发；NPTL是由Red Hat的开发者来开发的，两者同时进行。但是，NGPT已在2003年年中就被放弃了。
NPTL的使用与LinuxThreads极为相似，这是由于，其主要的抽象依然被内核认为是一个进程，而且新线程的创建，使用的还是clone()系统调用(来自NPTL的调用)。可是，NPTL需要专有的内核支持来实现在竞争情况下可使线程睡眠或被再唤醒的同步原语。用在这儿的原语，被认为是一个Futex。
NPTL号称是1x1的线程库，这是由于用户所创建的线程（通过pthread_create()库函数）与内核的调度实体（在Linux内是进程）1-1对应。这是最简单的合理线程实现了。一个备选方案是m x n的，就是说用户级线程要多于调度实体，如果以这种方式实现的话，由线程库负责在可用的调度实体上调度用户线程。这会使得线程上下文切换非常的快，因为它避免了系统调用，但是它也增加了复杂性和优先级反转的可能性。
NPTL的第一版发布在Red Hat 9.0中。老式的POSIX线程库众所周知的问题是有些时候线程会拒绝向系统让出控制权，因为这种事情发生时，它得不到让出控制权的机会。还有些事情Windows会做得更好。Red Hat在Java的站点上的一篇关于Java在Red Hat 9上的文章中声称NPTL已经解决了这些问题。
自从Red Hat Enterprise Linux第3版开始，NPTL就已经成为它的一部分,现在它已经完全的集成到Glibc中了。
LinuxThreads 和 NPTL
LinuxThreads 项目最初将多线程的概念引入了 Linux®，但是 LinuxThreads 并不遵守 POSIX 线程标准。尽管更新的 Native POSIX Thread Library（NPTL）库填补了一些空白，但是这仍然存在一些问题。本文为那些需要将自己的应用程序从 LinuxThreads 移植到 NPTL 上或者只是希望理解有何区别的开发人员介绍这两种 Linux 线程模型之间的区别。
当 Linux 最初开发时，在内核中并不能真正支持线程。但是它的确可以通过 clone() 系统调用将进程作为可调度的实体。这个调用创建了调用进程（calling process）的一个拷贝，这个拷贝与调用进程共享相同的地址空间。LinuxThreads 项目使用这个调用来完全在用户空间模拟对线程的支持。不幸的是，这种方法有一些缺点，尤其是在信号处理、调度和进程间同步原语方面都存在问题。另外，这个线程模型也不符合 POSIX 的要求。
要改进 LinuxThreads，非常明显我们需要内核的支持，并且需要重写线程库。有两个相互竞争的项目开始来满足这些要求。一个包括 IBM 的开发人员的团队开展了 NGPT（Next-Generation POSIX Threads）项目。同时，Red Hat 的一些开发人员开展了 NPTL 项目。NGPT 在 2003 年中期被放弃了，把这个领域完全留给了 NPTL。
尽管从 LinuxThreads 到 NPTL 看起来似乎是一个必然的过程，但是如果您正在为一个历史悠久的 Linux 发行版维护一些应用程序，并且计划很快就要进行升级，那么如何迁移到 NPTL 上就会变成整个移植过程中重要的一个部分。另外，我们可能会希望了解二者之间的区别，这样就可以对自己的应用程序进行设计，使其能够更好地利用这两种技术。
本文详细介绍了这些线程模型分别是在哪些发行版上实现的。
LinuxThreads 设计细节
线程 将应用程序划分成一个或多个同时运行的任务。线程与传统的多任务进程 之间的区别在于：线程共享的是单个进程的状态信息，并会直接共享内存和其他资源。同一个进程中线程之间的上下文切换通常要比进程之间的上下文切换速度更快。因此，多线程程序的优点就是它可以比多进程应用程序的执行速度更快。另外，使用线程我们可以实现并行处理。这些相对于基于进程的方法所具有的优点推动了 LinuxThreads 的实现。
LinuxThreads 最初的设计相信相关进程之间的上下文切换速度很快，因此每个内核线程足以处理很多相关的用户级线程。这就导致了一对一线程模型的革命。
让我们来回顾一下 LinuxThreads 设计细节的一些基本理念：
• LinuxThreads 非常出名的一个特性就是管理线程（manager thread）。管理线程可以满足以下要求：
o 系统必须能够响应终止信号并杀死整个进程。
o 以堆栈形式使用的内存回收必须在线程完成之后进行。因此，线程无法自行完成这个过程。
o 终止线程必须进行等待，这样它们才不会进入僵尸状态。
o 线程本地数据的回收需要对所有线程进行遍历；这必须由管理线程来进行。
o 如果主线程需要调用 pthread_exit()，那么这个线程就无法结束。主线程要进入睡眠状态，而管理线程的工作就是在所有线程都被杀死之后来唤醒这个主线程。
• 为了维护线程本地数据和内存，LinuxThreads 使用了进程地址空间的高位内存（就在堆栈地址之下）。
