多进程与多线程（六）--LinuxThreads

Linux内核对多进程和多线程的支持方式：

        线程机制支持并发程序设计技术，在多处理器上能真正保证并行处理。而在linux实现线程很特别，linux把所有的线程都当作进程实现。linux下线 程看起来就像普通进程(只是该进程和其他进程共享资源，如地址空间)。上述机制与Microsoft windows或是Sun Solaris实现差异很大。

        Linux的线程实现是在核外进行的，核内提供的是创建进程的接口do_fork()。内核提供了两个系统调用__clone()和fork()，最终都 用不同的参数调用do_fork()核内API。 do_fork() 提供了很多参数，包括CLONE_VM（共享内存空间）、CLONE_FS（共享文件系统信息）、CLONE_FILES（共享文件描述符表）、 CLONE_SIGHAND（共享信号句柄表）和CLONE_PID（共享进程ID，仅对核内进程，即0号进程有效）。当使用fork系统调用产生多进程 时，内核调用do_fork()不使用任何共享属性，进程拥有独立的运行环境。当使用pthread_create()来创建线程时，则最终设置了所有这 些属性来调用__clone()，而这些参数又全部传给核内的do_fork()，从而创建的”进程”拥有共享的运行环境，只有栈是独立的，由 __clone()传入。

         即：Linux下不管是多线程编程还是多进程编程，最终都是用do_fork实现的 多进程编程，只是进程创建时的参数不同，从而导致有不同的共享环境。Linux线程在核内是以轻量级进程的形式存在的，拥有独立的进程表项，而所有的创 建、同步、删除等操作都在核外pthread库中进行。pthread 库使用一个管理线程（__pthread_manager() ，每个进程独立且唯一）来管理线程的创建和终止，为线程分配线程ID，发送线程相关的信号，而主线程pthread_create()） 的调用者则通过管道将请求信息传给管理线程。

很多朋友都说使用多线程的好处是资源占用少，其隐含之意就是说进程占用资源比线程多，对吧？但实际上Linux下多进程是否就真的点用很多资源呢？ 暂且不说进程是否比线程占用资源多，就进程占用资源的多少情况而言，Linux确实是做得相当节省的。产生一个多进程时肯定是要产生的一点内存是要复制进 程表项，即一个task_struct结构，但这个结构本身做得相当小巧。其它对于一个进程来说必须有的数据段、代码段、堆栈段是不是全盘复制呢？对于多 进程来说，代码段是肯定不用复制的，因为父进程和各子进程的代码段是相同的，数据段和堆栈段呢？也不一定，因为在Linux里广泛使用的一个技术叫 copy-on-write，即写时拷贝。copy-on-write意味着什么呢？意味着资源节省，假设有一个变量x在父进程里存在，当这个父进程创建 一个子进程或多个子进程时这个变量x是否复制到了子进程的内存空间呢？不会的，子进程和父进程使用同一个内存空间的变量，但当子进程或父进程要改变变量x 的值时就会复制该变量，从而导致父子进程里的变量值不同。父子进程变量是互不影响的，由于父子进程地址空间是完全隔开的，变量的地址可以是完全相同的。

          Linux的”线程”和”进程”实际上处于一个调度层次，共享一个进程标识符空间，这种限制使得不可能在Linux上实现完全意义上的POSIX线程机 制，因此众多的Linux线程库实现尝试都只能尽可能实现POSIX的绝大部分语义，并在功能上尽可能逼近。Linux进程的创建是非常迅速的。内核设计 与实现一书中甚至指出Linux创建进程的速度和其他针对线程优化的操作系统（Windows,Solaris）创建线程的速度相比，测试结果非常的好， 也就是说创建速度很快。由于异步信号是内核以进程为单位分发的，而LinuxThreads的每个线程对内核来说都是一个进程，且没有实现”线程组”，因 此，某些语义不符合POSIX标准，比如没有实现向进程中所有线程发送信号，README对此作了说明。LinuxThreads中的线程同步很大程度上 是建立在信号基础上的，这种通过内核复杂的信号处理机制的同步方式，效率一直是个问题。LinuxThreads 的问题，特别是兼容性上的问题，严重阻碍了Linux上的跨平台应用（如Apache）采用多线程设计，从而使得Linux上的线程应用一直保持在比较低 的水平。在Linux社区中，已经有很多人在为改进线程性能而努力，其中既包括用户级线程库，也包括核心级和用户级配合改进的线程库。目前最为人看好的有 两个项目，一个是RedHat公司牵头研发的NPTL（Native Posix Thread Library），另一个则是IBM投资开发的NGPT（Next Generation Posix Threading），二者都是围绕完全兼容POSIX 1003.1c，同时在核内和核外做工作以而实现多对多线程模型。这两种模型都在一定程度上弥补了LinuxThreads的缺点，且都是重起炉灶全新设 计的。

          综上所述的结论是在Linux下编程多用多进程编程少用多线程编程。

         IBM有个家伙做了个测试，发现切换线程context的时候，windows比linux快一倍多。进出最快的锁（windows2k的 critical section和linux的pthread_mutex），windows比linux的要快五倍左右。当然这并不是说linux不好，而且在经过实际 编程之后，综合来看我觉得linux更适合做high performance server，不过在多线程这个具体的领域内，linux还是稍逊windows一点。这应该是情有可原的，毕竟unix家族都是从多进程过来的，而 windows从头就是多线程的。

如果是UNIX/linux环境，采用多线程没必要。

多线程比多进程性能高？误导！

应该说，多线程比多进程成本低，但性能更低。

在UNIX环境，多进程调度开销比多线程调度开销，没有显著区别，就是说，UNIX进程调度效率是很高的。内存消耗方面，二者只差全局数据区，现在内存都很便宜，服务器内存动辄若干G，根本不是问题。

多进程是立体交通系统，虽然造价高，上坡下坡多耗点油，但是不堵车。

多线程是平面交通系统，造价低，但红绿灯太多，老堵车。

我们现在都开跑车，油（主频）有的是，不怕上坡下坡，就怕堵车。

高性能交易服务器中间件，如TUXEDO，都是主张多进程的。实际测试表明，TUXEDO性能和并发效率是非常高的。TUXEDO是贝尔实验室的，与UNIX同宗，应该是对UNIX理解最为深刻的，他们的意见应该具有很大的参考意义

注：

关于那个critical section和pthread_mutex_t，critical section本质上是一个自旋锁，短期锁当然快，要比也该是和pthread_spinlock_t比。

mutex和critical section的确是不能比的。一个涉及到内核，一个没有涉及到内核。

1. 沙

   2010年7月10日08:43

   回复 |  引用 |  #1

   文章很有深度，我们把握一个尺度就可以了，在windows下使用线程，unix下则使用进程就可以了

2. 

   rjoo

   2010年9月9日13:49

   回复 |  引用 |  #2

   错的太多了，博主，应该看看新资料了。

   现在都2010年了，NPTL早就取代了老的Linux thread。而且通常多线程有性能优势，但是多进程更稳定，并且通常性能瓶颈不在于是进程模型还是线程模型而在于IO。

3. 

   rjoo

   2010年9月9日13:56

   回复 |  引用 |  #3

   关于那个critical section和pthread_mutex_t，critical section本质上是一个自旋锁，短期锁当然快，不知道你说的那个IBM的哥们怎么比的，要比也该是和pthread_spinlock_t比。

4. 

   admin

   2010年9月9日17:28

   回复 |  引用 |  #4

   rjoo挺热心的，呵呵，这篇文章不是我写的，但有几个地方我可以解答一下：

   1. Linux下没有线程的概念，pthread线程实质是通过轻量级进程实现的。你说瓶颈在IO，这一点我很赞同你的意见，作者如果能再写个IO操作的文章来的话就会更好了。

   2. mutex和critical section的确是不能比的。一个涉及到内核，一个没有涉及到内核。呵呵，很佩服你对这些东西的掌握程度，有机会多交流。

   ^_^

5. 

   定时

   2010年9月9日17:40

   回复 |  引用 |  #5

   我们组的最近项目的经验告诉我们能用多进程不用多线程，多线程安全编程难，而且锁会早成效率很低，甚至不如单线程，你说的NPTL我知道，他只是多线程优化了并不能改变多线程安全编程的问题，锁的问题。谢谢指教，实践出真知。
   @rjoo

6. 

   定时

   2010年9月9日17:44

   回复 |  引用 |  #6

   你说的锁，我确实不太了解，但是我们leader对它很了解，就是最近的一个项目，锁搞得他很郁闷，他也终于同意我的关键，尽可能不用多线程。
   @rjoo

7. 

   rjoo

   2010年9月29日13:41

   回复 |  引用 |  #7

   @admin 
   Linux下没有线程的概念，pthread线程实质是通过轻量级进程实现的—这是2.4内核以前的情况（实际上是2.0时引入的，那可实在是太久了），2.4内核引入NGPL，2.6内核线程支持改为NPTL。NPTL实现的是1：1的线程模型（有资料说Win也是这种实现，虽然不太确定，但我觉得可能性很大），而NGPT虽然是理论上最先进的m：n线程模型，但最后实现出来的性能差NPTL一大截，最后被抛弃。看看文中说法就知道要么文章写的很早，要么作者看了一堆十年前的资料。
   给个链接：
   http://www.kegel.com/c10k.html#threads.linuxthreads

8. 

   finalday

   2010年10月15日17:26

   回复 |  引用 |  #8

   忍不住跳出来说，作者对并发编程的理解还不行。
   比如说锁的问题，说得好像是多线程才需要的东西一样。如果一个应用多进程时完全不用锁，多线程也就多一个轻量级锁——锁一下，各回各家，每个线程用自己的专有存储，之后不就和多进程一样了？这样会被搞得很郁闷？当然不会。所以说明那个应用对于数据共享的需求不是这么简单，既然不是这么简单，多进程程序一样要加锁。多进程的加解锁代价可比多线程大得多了，共享数据和协作也麻烦多了。
   多线程编程难不难？难，但这是由于并发本身的难度引起的。“锁”，“安全编程”不管是多线程还是多进程都一样会遇到。
   多线程的最大优点是数据共享和协作方便。
   多进程的最大优点是挂了一个进程不会影响其他进程，资源也不会泄露，故比较能容忍程序员犯错。
   至于两者裸奔比性能，真的没啥意义。

http://blog.chinaunix.net/uid-20556054-id-3068371.html

http://www.softbin.com/html/2010/07/09/%E5%A4%9A%E8%BF%9B%E7%A8%8Bvs%E5%A4%9A%E7%BA%BF%E7%A8%8B%EF%BC%8C%E4%B8%80%E4%B8%AA%E9%95%BF%E6%9C%9F%E7%9A%84%E4%BA%89%E8%AE%BA.html