这几天由于工作需要，琢磨了一下Linux下的多线程的相关资料。Linux下最常用的多线程支持库为Pthread库，它是glibc库的组成部分。但是关于Pthread的说明文档非常缺乏，特别是对POSIX多线程规范的介绍以及pthread库中多线程实现方式的介绍实在是少之又少。而多线程编程对于系统程序员而言是必须掌握的技术，因此总是让学习中的程序员觉得头痛不以。我自己也没有太多多线程编程的经验，在这里只是把自己收集到的一些关于Linux上多线程还算新的资料进行汇总来抛砖引玉，以便相互学习交流。
这里顺便提一下市面上有的一本介绍多线程的书《Posix 多线程编程》，它是英文版《Programming with POSIX Muiltthread》中译本，这也是半年前我所能找到的唯一专题介绍多线程编程的书。我个人感觉这本书的前面1/3之一的内容写的还是不错的，但是后面的东西就非常晦涩并且有很多明显的文字错误。看看这本书的翻译者是好几个人，估计每个人的翻译能力不同造成了这本书的虎头蛇尾。 因此我不建议大家去买这本书作为圣经收藏。这本书前半步的内容主要围绕Posix的多线程，介绍的比较精彩的就是几个多线程编程模型，把多线程的互斥和同步机制介绍的挺酣畅的，推荐一看。 这些内容并非这本书首创，早在《UNIX网络编程》第二卷进程间通信就有了这些经典的介绍，但是能系统的把这些机制结合到多线程编程中来还是有可圈可点之处的。此外毕竟《UNIX网络编程》两卷内容太老，书也太厚了，并不是大多数程序员所能坐下来细细看的。这里我还想表达一下对微软在技术上的不足斥责。在msdn中platform sdk部分中的windows多线程编程的内容真是简陋的可笑，只有傻兮兮的建立和退出线程的函数，关于互斥，条件的介绍一概全无。只能在它的sample代码中自己去找，sample代码里面的线程同步方式居然是做一个死循环来死等，也不知道它把windows卖这么多钱是干什么吃的。 MFC中多线程的封装倒是看上去像那么一回事情了，但是我想象不出在如此简陋的系统api上微软到底是如何实现出MFC上线程功能的。拥护windows的人不要在这里砸鸡蛋，最好也能写一篇windows上的多线程介绍除了。这比砸鸡蛋来得有意义多了。 好了，书归正传继续说Linux上的多线程。
在Linux上，从内核角度而言，基本没有什么线程和进程的区别－－大家都是进程。一个进程的多个线程只是多个特殊的进程他们虽然有各自的进程描述结构，却共享了同一个代码上下文。在Linux上，这样的进程称为轻量级进程Light weight process。致此，就是关于线程的总体概念了，我们往往就在了解这个概念的情况下开始我们的多线程编程之旅。这对于多线程编程入门已经足够了，然而事实上线程却要复杂的多。 首先多线程间的优先级调度，内存资源（栈）分配和信号投递就不是简单的共享同一个进程代码上下文所能所能解决的。其次，效率的问题：如何有效的使用多cpu资源（2.4内核的多线程就无法使用多个cpu，一个进程的线程都被限制在同一个cpu上运行）。因此多线程库Pthread的实现并不是一件简单的事情，它建立在特有的线程模型之上。
在Linux 2.4内核中， Linux内核中使用了一个内核线程来处理用户态进程中的多个线程的上下文切换（线程切换）。由于内核中并没有什么线程组的概念，即一个进程的多个线程，因此必须依靠在pthread库中实现一个额外的线程来管理其他用户线程（即用户程序生成的线程）的建立，退出，资源分配和回收以及线程的切换。由于当时硬件并没有线程寄存器之类的冬冬来支持多线程，因此线程的切换性能和低下，并且需要引入复杂的机制在进程的栈中为各个线程划分出各自的栈数据所在位置，并且在切换时进行栈数据拷贝。而最大的问题是内核中缺乏对线程间的同步机制的支持，因此pthread库不得不在底层依靠信号方式来实现同步，因此线程互斥中的互斥量操作和条件量操作都转换为进程的信号操作。pthread的实现中充斥了极其复杂的信号操作。大家都知道信号本身是低速的通信方式，因此势必拖慢了线程的实际性能。最后的问题就是信号处理，还有由于内核对线程的无知，必须由管理线程来接收信号后投递给相应的线程，一方面是效率低，另外一方面由于信号产生的不确定性（比如读取一个文件的时候突然出错了），要准确投递所有的信号给正确的线程难以保证。
而在IA-32硬件结构中，出现了对线程寄存器的支持，因此Pthread的线程上下文切换速度有了很大提高。但是由于硬件限制局限，线程的数量必须小于8192个,反正我是觉得已经很多了。
于是从2.5代码开始Linux内核采用了NPTLNative Posix Thread Library）方式。NPTL的设计思想初稿可参考nptl-design.pdf( [url]http://people.redhat.com/drepper/nptl-design.pdf[/url] )
首先在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，当线程数量急遽增加的时候，消耗时间的差异更加明显。
在线程间同步试验中，频繁进出临界区的时间消耗只有原来的一半。
更多的用户测试报告可以看 [url]http://kerneltrap.org/node/422[/url]
至于如何在开发中使用NPTL可参考Migrating to Linux kernel 2.6 -- Part 5: Migrating apps to the 2.6 kernel and NPTL（ [url]http://linuxdevices.com/articles/AT6753699732.html[/url] ）。需要做的事情有这么几件。
1：使用2.6的内核的系统平台
2：确定你的gcc支持NPTL
用# getconf GNU_LIBPTHREAD_VERSION命令来查看gcc的编译时的对多线程的支持方式
如果返回的是linuxthreads-0.10，说明你的gcc不支持NPTL
如果返回的是nptl-0.60这样的信息，说明你的gcc能用来编译新的NPTL
这里顺便提一下市面上有的一本介绍多线程的书《Posix 多线程编程》，它是英文版《Programming with POSIX Muiltthread》中译本，这也是半年前我所能找到的唯一专题介绍多线程编程的书。我个人感觉这本书的前面1/3之一的内容写的还是不错的，但是后面的东西就非常晦涩并且有很多明显的文字错误。看看这本书的翻译者是好几个人，估计每个人的翻译能力不同造成了这本书的虎头蛇尾。 因此我不建议大家去买这本书作为圣经收藏。这本书前半步的内容主要围绕Posix的多线程，介绍的比较精彩的就是几个多线程编程模型，把多线程的互斥和同步机制介绍的挺酣畅的，推荐一看。 这些内容并非这本书首创，早在《UNIX网络编程》第二卷进程间通信就有了这些经典的介绍，但是能系统的把这些机制结合到多线程编程中来还是有可圈可点之处的。此外毕竟《UNIX网络编程》两卷内容太老，书也太厚了，并不是大多数程序员所能坐下来细细看的。这里我还想表达一下对微软在技术上的不足斥责。在msdn中platform sdk部分中的windows多线程编程的内容真是简陋的可笑，只有傻兮兮的建立和退出线程的函数，关于互斥，条件的介绍一概全无。只能在它的sample代码中自己去找，sample代码里面的线程同步方式居然是做一个死循环来死等，也不知道它把windows卖这么多钱是干什么吃的。 MFC中多线程的封装倒是看上去像那么一回事情了，但是我想象不出在如此简陋的系统api上微软到底是如何实现出MFC上线程功能的。拥护windows的人不要在这里砸鸡蛋，最好也能写一篇windows上的多线程介绍除了。这比砸鸡蛋来得有意义多了。 好了，书归正传继续说Linux上的多线程。
在Linux上，从内核角度而言，基本没有什么线程和进程的区别－－大家都是进程。一个进程的多个线程只是多个特殊的进程他们虽然有各自的进程描述结构，却共享了同一个代码上下文。在Linux上，这样的进程称为轻量级进程Light weight process。致此，就是关于线程的总体概念了，我们往往就在了解这个概念的情况下开始我们的多线程编程之旅。这对于多线程编程入门已经足够了，然而事实上线程却要复杂的多。 首先多线程间的优先级调度，内存资源（栈）分配和信号投递就不是简单的共享同一个进程代码上下文所能所能解决的。其次，效率的问题：如何有效的使用多cpu资源（2.4内核的多线程就无法使用多个cpu，一个进程的线程都被限制在同一个cpu上运行）。因此多线程库Pthread的实现并不是一件简单的事情，它建立在特有的线程模型之上。
在Linux 2.4内核中， Linux内核中使用了一个内核线程来处理用户态进程中的多个线程的上下文切换（线程切换）。由于内核中并没有什么线程组的概念，即一个进程的多个线程，因此必须依靠在pthread库中实现一个额外的线程来管理其他用户线程（即用户程序生成的线程）的建立，退出，资源分配和回收以及线程的切换。由于当时硬件并没有线程寄存器之类的冬冬来支持多线程，因此线程的切换性能和低下，并且需要引入复杂的机制在进程的栈中为各个线程划分出各自的栈数据所在位置，并且在切换时进行栈数据拷贝。而最大的问题是内核中缺乏对线程间的同步机制的支持，因此pthread库不得不在底层依靠信号方式来实现同步，因此线程互斥中的互斥量操作和条件量操作都转换为进程的信号操作。pthread的实现中充斥了极其复杂的信号操作。大家都知道信号本身是低速的通信方式，因此势必拖慢了线程的实际性能。最后的问题就是信号处理，还有由于内核对线程的无知，必须由管理线程来接收信号后投递给相应的线程，一方面是效率低，另外一方面由于信号产生的不确定性（比如读取一个文件的时候突然出错了），要准确投递所有的信号给正确的线程难以保证。
而在IA-32硬件结构中，出现了对线程寄存器的支持，因此Pthread的线程上下文切换速度有了很大提高。但是由于硬件限制局限，线程的数量必须小于8192个,反正我是觉得已经很多了。
于是从2.5代码开始Linux内核采用了NPTLNative Posix Thread Library）方式。NPTL的设计思想初稿可参考nptl-design.pdf( [url]http://people.redhat.com/drepper/nptl-design.pdf[/url] )
首先在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，当线程数量急遽增加的时候，消耗时间的差异更加明显。
在线程间同步试验中，频繁进出临界区的时间消耗只有原来的一半。
更多的用户测试报告可以看 [url]http://kerneltrap.org/node/422[/url]
至于如何在开发中使用NPTL可参考Migrating to Linux kernel 2.6 -- Part 5: Migrating apps to the 2.6 kernel and NPTL（ [url]http://linuxdevices.com/articles/AT6753699732.html[/url] ）。需要做的事情有这么几件。
1：使用2.6的内核的系统平台
2：确定你的gcc支持NPTL
用# getconf GNU_LIBPTHREAD_VERSION命令来查看gcc的编译时的对多线程的支持方式
如果返回的是linuxthreads-0.10，说明你的gcc不支持NPTL
如果返回的是nptl-0.60这样的信息，说明你的gcc能用来编译新的NPTL
3：重新在这样的系统环境中编译你的程序，不需要改变程序中对pthread的调用（但是某些函数被取消了）
本文转自nathanxu 51CTO博客，原文链接：http://blog.51cto.com/nathanxu/56649，如需转载请自行联系原作者
