Linux多线程编程和Linux26下的NPTL.docVIP

Linux多线程编程和Linux 2.6下的NPTL这几天由于工作需要，琢磨了一下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