并行程序设计探讨（3）——Windows和Linux对决(多进程多线程)

前面的博文经过分析总结，最后得出两种并行技术：多进程多线程、多机协作。对于多进程和多线程来说，最有代表性且最常见的的莫过于Windows和Linux（作为UNIX类操作系统的代表，下同）这两个操作系统了。

真是冤家路窄，Windows和Linux这对冤家在这里又碰面了！！

当然，我这里不是要挑起Windows和Linux谁优谁劣的争论，对于一个真正的技术人来说，Windows和Linux本身并没有优劣之分，只有在不同的使用场景下用谁会更好的问题。之所以将Windows和Linux拿来对比，是因为对比更加容易让人理解，记忆也更加深刻！

下面我们首先从多进程和多线程的实现机制方面来对比Windows和Linux。

                                         多进程多线程实现机制

说起进程和线程，估计大家都会立刻想起那句耳熟能详的解释“进程是资源分配的最小单位，线程是运行的最小单位”！。

理论上来说这是对的，但实际上来说就不一定了，例如Windows有进程和线程的概念，而传统UNIX却只有进程的概念（例如经典的《UNIX环境高级编程》中就没有多线程的概念，但Solaris、AIX等又有另外的实现，此处暂且不表），Linux也有进程和线程的概念，但实现机制和Windows又不一样，真是林子大了什么鸟都有：）

有几个进程、线程相关的概念首先要简单介绍一下：

1.1   概念介绍

1.1.1  进程

资源分配最小单位，有的操作系统还是运行最小单位；

1.1.2   线程

运行最小单位，也是CPU调度的最小单位；

1.1.3   ULT、KLT

用户态线程和内核态线程；主要的区分就是“谁来管理”线程，用户态是用户管理，内核态是内核管理（但肯定要提供一些API，例如创建）。

简单对比两者优劣势：

1）可移植性：因为ULT完全在用户态实现线程，因此也就和具体的内核没有什么关系，可移植性方面ULT略胜一筹；

2）可扩展性：ULT是由用户控制的，因此扩展也就容易；相反，KLT扩展就很不容易，基本上只能受制于具体的操作系统内核；

3）性能：由于ULT的线程是在用户态，对应的内核部分还是一个进程，因此ULT就没有办法利用多处理器的优势，而KLT就可以通过调度将线程分布在多个处理上运行，这样KLT的性能高得多；另外，一个ULT的线程阻塞，所有的线程都阻塞，而KLT一个线程阻塞不会影响其它线程。

4）编程复杂度：ULT的所有管理工作都要由用户来完成，而KLT仅仅需要调用API接口，因此ULT要比KLT复杂的多；

1.1.4   POSIX

为了解决不同操作系统之间移植时接口不兼容而制定的接口标准，详见维基百科解释：http://zh.wikipedia.org/wiki/POSIX。

1.1.5  NPTL

为了解决Linux原有线程实现机制的缺陷而创立的一个开源项目，从2.4开始就有发布版本采用NPTL来实现多线程支持了。详见维基百科解释http://zh.wikipedia.org/wiki/Native_POSIX_Thread_Library。

1.1.6   LWP

Lightweight Process，轻量级进程，看名字有点奇怪，为什么叫轻量级进程呢？为什么又要用轻量级线程呢？

看了前面ULT和KLT的比较，估计大家也发现了一个问题：所谓的ULT，因为不能利用多处理器的优势和线程互相阻塞，其实完全不能堪重任，但对于传统UNIX和Linux这类操作系统，内核设计和实现的时候就没有线程这种对象，那怎么实现多线程呢？

天才们于是想出了LWP这个招数，说白了这就是一个“山寨版的进程”，完全具有了山寨的一切特征：

文件系统是原来的进程的；

文件描述符是原来的进程的；

信号处理是原来的进程的；

地址空间是原来的进程的；

但就是进程ID不是原来的进程的，你说像不像BlackBerry的山寨版BlockBerry？

详情请参考维基百科解释：http://en.wikipedia.org/wiki/Light-weight_process

1.2  详细对比

1.2.1  Windows

在此要向Windows致敬：至少相比Linux来说，Windows在线程上的支持是Linux不能比的（不要跟我提DOS哈）！

Windows的实现机制简单来说就是前面提到的KLT，即Windows在内核级别支持线程。每个Windows进程至少有一个线程，系统调度的时候也是调度线程。

当创建一个进程时，系统会自动创建它的第一个线程，称为主线程。然后，该线程可以创建其他的线程，而这些线程又能创建更多的线程。

Windows已经提供了线程编程系列的API，这里就不详述了。

1.2.2  Linux

Linux不同的版本有不同的实现，2.0~2.4实现的是俗称LinuxThreads的多线程方式，到了2.6，基本上都是NPTL的方式了。下面我们分别介绍。

1.2.2.1 LinuxThreads      

注：以下内容主要参考“杨沙洲 (mailto:pubb@163.net?subject=Linux 线程实现机制分析&cc=pubb@163.net)国防科技大学计算机学院”的“Linux 线程实现机制分析”。

这种实现本质上是一种LWP的实现方式，即通过轻量级进程来模拟线程，内核并不知道有线程这个概念，在内核看来，都是进程。

Linux采用的“一对一”的线程模型，即一个LWP对应一个线程。这个模型最大的好处是线程调度由内核完成了，而其他线程操作（同步、取消）等都是核外的线程库函数完成的。

在LinuxThreads中，专门为每一个进程构造了一个管理线程，负责处理线程相关的管理工作。当进程第一次调用pthread_create()创建一个线程的时候就会创建并启动管理线程。然后管理线程再来创建用户请求的线程。也就是说，用户在调用pthread_create后，先是创建了管理线程，再由管理线程创建了用户的线程。

这种通过LWP的方式来模拟线程的实现看起来还是比较巧妙的，但也存在一些比较严重的问题：

1）线程ID和进程ID的问题

按照POSIX的定义，同一进程的所有的线程应该共享同一个进程和父进程ID，而Linux的这种LWP方式显然不能满足这一点。

2）信号处理问题

异步信号是以进程为单位分发的，而Linux的线程本质上每个都是一个进程，且没有进程组的概念，所以某些缺省信号难以做到对所有线程有效，例如SIGSTOP和SIGCONT，就无法将整个进程挂起，而只能将某个线程挂起。

3）线程总数问题

LinuxThreads将每个进程的线程最大数目定义为1024，但实际上这个数值还受到整个系统的总进程数限制，这又是由于线程其实是核心进程。

4)管理线程问题

管理线程容易成为瓶颈，这是这种结构的通病；同时，管理线程又负责用户线程的清理工作，因此，尽管管理线程已经屏蔽了大部分的信号，但一旦管理线程死亡，用户线程就不得不手工清理了，而且用户线程并不知道管理线程的状态，之后的线程创建等请求将无人处理。

5)同步问题

LinuxThreads中的线程同步很大程度上是建立在信号基础上的，这种通过内核复杂的信号处理机制的同步方式，效率一直是个问题。

6）其他POSIX兼容性问题

Linux中很多系统调用，按照语义都是与进程相关的，比如nice、setuid、setrlimit等，在目前的LinuxThreads中，这些调用都仅仅影响调用者线程。

7）实时性问题

线程的引入有一定的实时性考虑，但LinuxThreads暂时不支持，比如调度选项，目前还没有实现。不仅LinuxThreads如此，标准的Linux在实时性上考虑都很少。

1.2.2.2   NPTL的实现

NPTL，Native POSIX Thread Library，天生的POSIX线程库。从命名上也可以看出所谓的NPTL就是针对原来的LinuxThreads的，不然为啥叫“Native”呢：）

本质上来说，NPTL还是一个LWP的实现机制，但相对原有LinuxThreads来说，做了很多的改进。下面我们看一下NPTL如何解决原有LinuxThreads实现机制的缺陷。

1）线程ID和进程ID问题

新的exec函数能够创建和原有进程ID一样ID的新进程，这样所有的线程ID都是一样的；且/Proc目录下只会显示进程的初始线程（初始线程就代表整个进程，类似于Windows的进程中第一个线程s），不会再像以前LinuxThreads机制时每个线程在proc目录下都有记录。

2）信号处理问题

内核实现了POSIX要求的线程信号处理机制，发送给进程的信号将由内核分发给一个合适的线程处理，对于致命和全局的信号（例如Stop，Continue， Pending）,所有的线程都同步处理。

3）线程总数问题

内核经过扩展，能够处理任意数量的线程。PID空间经过扩展后，在IA-32系统上能够最大支持20亿线程。

4）管理线程问题

去掉管理进程，管理进程的任务由扩展后的clone函数完成；增加了exit_group的系统调用，用于退出整个进程；

5）信号同步问题

实现了一个叫做Futex（Fase Userspace Mutex，注意不是Mutex）机制用来完成线程间同步，Futex的主要操作是在用户态完成的，这样解决了依靠内核信号机制进行同步的效率问题。详细请参考http://zh.wikipedia.org/wiki/Futex。

当然，NPTL虽然做了很多改进，但依然不是100% POSIX兼容的，LinuxThreads的第6个和第7个问题在NPTL机制下依然没有解决，但这并不掩盖NPTL带来的巨大改进，下面是性能对比图：

NPTL官方的文档：http://people.redhat.com/drepper/nptl-design.pdf。

1.3    对决？

看了前面的分析，大家可能纳闷了，这哪里是对决哦？全部是讲Linux的实现了。

其实我也郁闷，本来应该更加详细的介绍Windows实现机制的，但由于Linux的不争气，全部用来变成对它的分析了。

==========================未完待续===============================