linux 2.4 和linux2.5以上 多线程的不同

在Linux 2.4内核中，Linux内核中使用了一个内核线程来处理用户态进程中的多个线程的上下文切换（线程切换）。
由于内核中并没有什么线程组的概念，即一个进程的多个线程，因此必须依靠在pthread库中实现一个额外的线程来管理其他用户线程（即用户程序生成的线程）的建立，
退出，资源分配和回收以及线程的切换。由于当时硬件并没有线程寄存器之类的东东来支持多线程，
因此线程的切换性能低下，并且需要引入复杂的机制在进程的栈中为各个线程划分出各自的栈数据所在位置，
并且在切换时进行栈数据拷贝。而最大的问题是内核中缺乏对线程间的同步机制的支持，
因此pthread库不得不在底层依靠信号方式来实现同步，因此线程互斥中的互斥量操作和条件量操作都转换为进程的信号操作。
pthread的实现中充斥了极其复杂的信号操作。大家都知道信号本身是低速的通信方式，因此势必拖慢了线程的实际性能。
最后的问题就是信号处理，还有由于内核对线程的无知，必须由管理线程来接收信号后投递给相应的线程，
一方面是效率低，另外一方面由于信号产生的不确定性（比如读取一个文件的时候突然出错了），要准确投递所有的信号给正确的线程难以保证。

而在IA-32硬件结构中，出现了对线程寄存器的支持，因此Pthread的线程上下文切换速度有了很大提高。但是由于硬件限制局限，线程的数量必须小于8192个,反正我是觉得已经很多了。
于是从2.5内核代码开始Linux内核采用了NPTL（Native Posix Thread Library）方式。NPTL的设计思想初稿可参考nptl-design.pdf(http://people.redhat.com/drepper/nptl-design.pdf)
首先在IA-32和x86-64位体系结构上能实现任意数量的线程数量。通过引入了TLS系统调用可以建立多个GDT全局描述符表，每个cpu维护一个描述符表，每个表项存放一个线程。
其次，clone系统调用优化了线程的建立和结束功能。也不再需要额外的调度线程的帮助就可以回收线程资源了。
其三，信号投递由内核完成，而不再需要额外的用户态管理线程的帮助，而严重错误信号之间结束整个进程。
其四，引入了新的退出系统调用exit_group（）。原来的exit保留用于退出单个线程，exit_group用于退出整个进程。
其五， 新的exec调用会先结束到一个进程中的所有线程后再载入新程序的执行，而不是只结束调用的线程。
其六，所有线程的资源使用情况（cpu资源，内存资源）会报告给整个进程，而不再是只报告给初始化线程
其七，proc文件系统中只显示初始化线程的信息，而不再是所有线程的信息（上万个线程会把proc文件系统拖死）
其八， 支持线程脱离， 执行Pthread_join的线程不需要再执行no wait。
其九，由内核来维护初始化线程（变成内核线程了），并在proc文件系统中显示其状态，并维护直到所有线程退出来保证信号的投递。
其十，内核支持无限制的线程数量。
最后，允许pthread_join在子线程已死之后返回，即pthread_join的返回和子线程状态变成异步的了，提高了性能。
根据报告，NPTL中线程的启动和中止时间消耗只有Linuxthread的大约1/8，当线程数量急遽增加的时候，消耗时间的差异更加明显。
在线程间同步试验中，频繁进出临界区的时间消耗只有原来的一半。
更多的用户测试报告可以看 http://kerneltrap.org/node/422
至于如何在开发中使用NPTL可参考Migrating to Linux kernel 2.6 -- Part 5: Migrating apps to the 2.6 kernel and NPTL（http://linuxdevices.com/articles/AT6753699732.html）。需要做的事情有这么几件。
1：使用2.6的内核的系统平台
2：确定你的gcc支持NPTL
用# getconf GNU_LIBPTHREAD_VERSION命令来查看gcc的编译时的对多线程的支持方式
如果返回的是linuxthreads-0.10，说明你的gcc不支持NPTL
如果返回的是nptl-0.60这样的信息，说明你的gcc能用来编译新的NPTL
3：重新在这样的系统环境中编译你的程序，不需要改变程序中对pthread的调用（但是某些函数被取消了）