UNIX的传统倾向于将一个任务交给一个进程全权受理，但是一个任务内部也不仅仅是一个执行绪，比如一个公司的所有成员，大家都在做同一件事，每个人却只 负责一部分，粒度减小之后，所有的事情便可以同时进行，不管怎样，大家还都共享着所有的资源。因此就出现了线程。线程其实就是共享资源的不同的执行绪。线 程的语义和朴素的UNIX进程是不同的。
0.原始进程模型-著名的fork调用
朴素的UNIX进程依托于著名的fork调用， 就是这个fork调用让UNIX进程和Windows进程截然不同，也正是因为这个fork调用，使二者没有兼容的余地。这个fork调用的根源有久远的 历史。早在UNIX之前的大型操作系统中，它就存在了，UNIX刚出现的1969年，其实并未引入fork调用，当时之有两个固定的进程连接两个终端。当 fork调用引入后，进程的数量便快速增加了，注意，此时暂且还没有exec调用！
在理解fork背后的哲学之前，先看一下什么是fork。fork就是叉子，由同一个叉子柄逐渐分叉，变成一把叉子，也类似那种道生一，一生二，二生三， 三生万物。我们看到，有了fork，理论上可以生成无数的进程，它们都可以向上回溯到相同的根！为何UNIX会采用这个模型？我们首先要理解，在还没有 “可执行文件”概念的时候，进程意味着什么。
试想程序最初是怎么录入到计算机的。今天它们理所当然地存在于磁盘上，作为“可执行文件”已经深入人心，可是在1950-1960年代初，程序都是现场录 入的，通过原始的纸带或者携带很重的磁带，文件系统还没有概念，整个纸带，磁带上的内容就是计算机要执行的程序，执行完了，想执行另一个程序，就要换介 质...人们写一个程序当然是为了做一件不止做一次的事，因此如果可以有多个“进程”同时执行纸带/磁带上的程序，系统的吞吐率将大大提高，注意，多个进 程执行的是同一个程序！这是最朴素的分时系统进程模型。fork在伯克利分时系统应运而生！fork提供了复制当前执行流的手段，fork出来的所有子进 程可以方便地执行相同的代码。
这个著名的fork调用深深影响了人们如何解释分时系统！自然而然在1970年代初引入了朴素的UNIX，说fork调用著名，就是因为它跟随 UNIX(以及类UNIX，比如Linux)至今，直接影响了UNIX的进程模型。现在总结UNIX为何采用fork调用来生成进程。我们知道从0到1很 难，从1到2相对容易，也比较难，从2到3...就很简单了。这就是道生一，...三生万物！1969年的UNIX中已经有了两个进程，使用fork可以 超级简单地实现二生三，三生万物，于是，也许是一种巧合，早先的伯克利分时系统的fork正好就在那里，便被托马斯引入了UNIX。
我想说一下为何是三生万物而不是二生万物。道生一这个是最难的，我们都知道。0和1是两个极其特殊的数字，0更加特殊。2也比较特殊，但是3就很一般了， 为何2特殊呢？我不想用博弈理论来描述，只是举一个例子，2个人在一起，闻到一股屁味，每个人都肯定能百分百确定是谁放的，如果是我，那我肯定知道，如果 我没有放，那肯定是对方，当然两人一起放的几率也是有的。但是3个人在一起的时候，除了真正放屁的那个人之外的2个人根本无法判断这个屁到底是谁放的。这 就是3和0，1，2的本质区别。所以三生万物。
1.UNIX进程模型
在UNIX伊始，进程的概念和其史前前辈是一致的，那个时 候文件系统相当不成熟，程序员关注的是执行好不容易写好的任务而不是编写任务本身(首先是没有那么大的需求，其次是信息存储是一个问题，没有互联网，可以 对比一下如今的AppStore...)。fork调用便直接将UNIX的进程组织成了tree，于是：
1.0号swap/sched进程和1号init进程便有了特殊地位；
2.形成了谁fork谁wait并回收的模型，在tree组织中这个很重要，便于资源回收；
3.如果父进程先退出，将所有子进程过继给init，这导致init必须存在且不容退出，总之，任何进程不能脱离整个进程tree。
总之，朴素的UNIX进程就是处在一棵树的某个节点的可执行对象。注意，它是可执行对象。
UNIX进程模型就是在上述基本原则上构建的，除此之外，在外围，UNIX延续了歇菜的Multics项目的shell思想，为每一个终端开放了一个 shell。shell是UNIX系统的第二个重要特征(如果先不说文件抽象的话！)，它需要fork出来的进程exec出一个新的不同的执行流。从以上 fork/exec的历史上看，它们从一开始就是分离的，这就构建了完整的UNIX进程模型：fork+exec。
我们看一下UNIX的进程模型可以构建哪些东西。早期的UNIX将进程进行了组织，伙同终端的概念，UNIX给出了进程组，会话的概念。
进程组是相关联的一组进程的集合，比如管道符连接的各个命令。更多的是它们之间的关联由用户来解释。会话则是进程组的集合，会话的意义在于用户可以方便地 让多个进程组以某种形式共享终端访问权。因为坐在一个终端前的是一个人，他每次执行一个操作，这个操作作用给谁就是一个问题。他可以创建一个会话，该会话 内创建多个进程组，他以自己的方式让不同的进程组轮流成为前台进程组从而操作它。会话和进程组的概念可以理解成由操作员控制的分时系统，只是调度者不再是 操作系统，而成了终端前的操作员。和每个CPU同时只能有一个进程运行类似，每一个终端会话同时只能有一个前台进程组。
我们可以看到，UNIX进程模型构建的进程组织自然而然形成了一个分级的分时调度层次，最底层是进程，由操作系统内核调度，然后是进程组，协作完成一个任 务，组织多个进程，由创建所属会话的操作员调度。在这个分级的层次底层，所有的进程组织成一棵tree。这就是完整的UNIX进程模型构建的图景。之所以 可以构建如此美丽的图景，fork+exec是基本原则，fork和exec之间，给了进程更多的控制自己的空间，如何控制自己属于哪一个组或者会话，由 进程自己决定而不是调用者决定，相反的例子请看一下Win32 API的CreateProcess。现在麻烦来了，线程出现了，该怎么办？如果你想知道Linux是怎么创造历史的，请直接跳到最后。
我之所以没有提及任何UNIX版本对上述构建的实现，是因为思想远比实现更重要，实现反而会拖累你构建新的模型。本文的最后，我会说明Linux是如何调和不同的进程模型之间的语义的，同时印证了UNIX进程模型的先进性。
2.提供资源环境的进程模型
Windows NT虽然在很多方面都借鉴了UNIX的思想，但是在进程模型上却采用了一种截然不同的思路。Windows NT出生的1990年代，应用已经开始遍地开花，文件系统也已经非常成熟，可执行文件的概念延续自MS-DOS时代(其实UNIXv6版本就有可执行文件 的概念，在UNIX引入exec调用之后，可执行文件仅仅是进程的后备资源，仅此而已)，人们可以基于Win32 API开发大量不同的程序，然后让它们分别运行，如果你想让一个程序执行多次，多点击它几次便是了。
在这样的时代，正如本文最初所说的，执行的粒度细化到了一个程序的内部。一个应用程序要完成一项任务，需要做不同的几件事，可能需要同时进行这几件事，类 似数学中的统筹方法。进程，在WinNT中也可以等同于从可执行文件中抽取出来的命名资源集合，已经不再适合作为可执行的对象，真正可执行的对象成了线 程。此时的进程只是提供了一个资源环境，线程使用这些可以共享的资源共同完成具体的事情。这种提供资源环境的进程模型我称为资源模型。
在本小节，我虽然以WinNT作为例子来描述另外一种进程模型，只是因为它作为这种模型的代表比较纯粹。实际上，很多的UNIX版本也在努力融合fork模型和资源模型这两者，企图既能继承UNIX的语义，又能实现多线程调度。
3.两种模型的调和
首先，fork模型和资源模型的冲突是明显的，典型体现于以下两个方面：
1.信号问题：到底哪个线程执行信号处理；
2.fork语义：假设已经运行了一个线程，在其中执行了fork，如何来解释fork的是哪个执行流；
其中第一个问题比较好解决，规定如果不是线程自身引发的异常导致的信号，就由任意线程来处理，反之由引发异常的线程来处理。第二个问题比较棘手，棘手之处在于某个UNIX是怎么实现进程模型的。
在进程结构体或者u区中维护一个链表，保存线程控制块指针！Oh，NO！这是怎么回事啊！UNIX怎么会忘了可执行的对象是进程啊！如此一来，进程岂不成 了线程的容器？直接倒向了资源模型，然而自己确实是纯正的UNIX！设计LWP是一个好方案吗？可能是，但是它引入很多的高层抽象，显得复杂了，如果几年 后再引入一个新的什么什么程呢？总之，任何修改朴素UNIX进程模型的方法都不是好方法。那么用户库级别的线程呢？这不属于内核的范畴，但表现了内核的无 能为力。
抛开实现，回到思想。我们再来看看进程，进程组，会话之间的关系，最基本的可执行对象是进程，上面的进程组，会话都是以某种组织形式对进程集合的封装，每 个集合都有一系列的资源可供这个集合中的进程共享。比如会话的环境变量，进程组的命令行变量等，线程是什么呢，线程不就是一组执行流的集合共享内存地址空 间吗？明白了些什么吗？如果不明白，我们可以把UNIX进程模型图景中的进程改成调度实体，只需要在这个图景的基础上往下走一层，线程自然而然就被支持 了：
线程，线程集合，进程组，会话...
换成调度实体的说法，就是：
调度实体，调度实体组，进程组，会话...
就 像进程组里面可以只有一个进程，组ID等于进程ID一样，进程里面也可以只有一个线程，线程ID就是进程ID。一切都统一到这个UNIX进程模型的图景中 了，如果一个线程集合只有一个线程，那么我们就称其为进程，如果拥有不止一个线程，我们就称这个集合为进程，而集合的元素为线程。其实，此时此刻，怎么称 呼已经无所谓了。
现在还缺什么？缺的是如何实现线程集合共享内存地址空间。传统的UNIX fork模型无疑无法做到这一点，因为它没有任何参数用来指示实现这种行为。于是需要稍微修改一下fork语义，引入一个clone调用，含有用户可以控制的参数：
int clone(int (*fn)(void *), void *child_stack,
int flags, void *arg, ...
/* pid_t *ptid, struct user_desc *tls, pid_t *ctid */ );
用户不但可以控制用户栈的位置，还可以有诸多的flags可供选择，如果要共享调用者的内存，CLONE_VM这个标志无疑是需要的，当然想clone线程不仅仅需要这一个标志，这里就不细说了，具体可以参考NPTL最新规范。
4.Linux的对UNIX进程模型的实现
Linux 实现的线程支持非常帅，它几乎没有触动任何已经有的task_struct结构体，也没有改变任何既有的fork语义。它只是引入了一个PID类型，叫做 TGID，即进程组ID。Linux中的可执行对象就是task_struct，而且只有task_struct。每一个task_struct拥有不止 一个ID，依照这些ID的不同的解释方式即不同的类型，将task_struct定位到一个进程或者是一个进程的某个线程。ID类型如下所示：
enum pid_type
{
PIDTYPE_PID,
PIDTYPE_TGID,
PIDTYPE_PGID,
PIDTYPE_SID,
PIDTYPE_MAX
};
其中：
PIDTYPE_PID：调度实体ID。如果该task_struct是一个进程的线程，那么它就是线程ID，如果该进程只有唯一的线程，那么它同时也是进程ID；
PIDTYPE_TGID,：线程集合ID。如果该task_struct所属的进程拥有多个线程，它就是进程ID，如果只有一个线程，它等同于PIDTYPE_PID；
PIDTYPE_PGID：进程组ID。不解释；
PIDTYPE_SID：会话ID。不解释。
根据上述解释，不管一个进程拥有一个线程还是拥有多个线程，其进程ID即PID均等于PIDTYPE_TGID标识的ID。而PIDTYPE_PID标识的ID则根据具体情况给予不同的解释。具体实施如下：
1.每一个task_struct均有一个本PID命名空间内唯一的ID标识符，初始化时将其同时赋给进程ID和线程ID；
2.如果该task_struct是一个进程的第一个线程，即由标准的fork调用创建，那么保持1的初始化数值不变；
3.如果该task_struct不是一个进程的第一个线程，即由带有CLONE_VM等的clone调用创建，那么将当前调用者的PIDTYPE_TGID标识的ID覆盖新task_struct的PIDTYPE_TGID标识的ID；
4.关于进程组ID以及会话ID的设置，有专门的setpgid， setpgrp，setsid等系统调用来完成，实现很类似上述进程和线程；
5.每个task_struct中有4个pid结构体，将这些pid结构体而不是task_struct本身用链表连接起来，指示谁是进程，谁是哪个进程的线程，谁是哪个进程组当头的组成员...
总之，在Linux中，不管是线程，还是进程，都是使用task_struct这个结构体，由其PID type的值的连接方式指示如何构建UNIX进程模型的图景，这真的是太帅了。个人认为还是用一张图表示连接方式比较直观，文字表达在这方面弱爆了：
wKiom1RBxlWAU1nUAApC91id4Ak872.jpg
如 果理解了上面的图，就会明白Linux在实现UNIX进程模型方面做的是多么帅。如此精简的一个模型和Linux如此精简的实现正好搭配，不知为何被传统 的UNIX引到了那么复杂的方向...Linux的实现明显洞察到了UNIX进程模型的层次化结构，即进程，进程组，会话这三个层次，如果再往下延伸一个 层次，将task_struct向下移动到最底层，就基本绘制出了上面的图景。
5.一段富有诗意的话
丹尼斯.里奇在回顾UNIX的发展史时，在最后说了一段话，这段话简直出自诗人之口，此诗意只有真情实感真性情方可抒发，可见丹尼斯.里奇对UNIX的感情是多么特殊：
One of the comforting things about old memories is their tendencyto take on a rosy glow.The programming environment provided by the early versions of Unix seems,when described here, to be extremely harsh and primitive.I am sure that if forced back to the PDP-7 I would find it intolerably limiting andlacking in conveniences.Nevertheless, it did not seem so at the time;the memory fixes on what was good and what lasted, and on the joy of helpingto create the improvements that made life better.In ten years, I hope we can look back with the same mixed impressionof progress combined with continuity.
©著作权归作者所有：来自51CTO博客作者dog250的原创作品，如需转载，请注明出处，否则将追究法律责任
Windows模型操作系统
随时随地看视频
