UNIX 进程管理 Unix/Linux fork前传

发布时间：2022-10-24 10:51:11 所属栏目：Unix 来源：

导读：　　本文是的前传。

　　fork的由来

　　fork的思想在UNIX出现几年前就出现了，时间大概是1963年，这比UNIX在PDP-7上的第一个版本早了6年。

　　1963年，计算机科学家Melvin Conway(以Conway’s La

　　本文是的前传。

　　fork的由来

　　fork的思想在UNIX出现几年前就出现了，时间大概是1963年，这比UNIX在PDP-7上的第一个版本早了6年。

　　1963年，计算机科学家Melvin Conway(以Conway’s Law闻名于世)写下一篇论文，正式提出了fork思想，该论文链接：

　　A Multiprocessor System Design：

　　fork的思想最初是Conway作为一种多处理器并行的方案提出来的，这个想法非常有意思。简而言之，fork思想来源于流程图。

　　我们看一个普通的流程图：

　　UNIX 进程管理_僵尸进程和孤儿进程_管理用户会话连接的进程

　　如果我们承认一个计算机程序可以表示为一个流程，那么我们就不能否认这种并行方案是正确的。

　　你看，流程图的分枝处，fork-叉子，多么形象！

　　一个流程图上的分支点分裂出来的分支显然是逻辑独立的，这便是可并行的前提，于是它们便可以表现为不同的处理进程(process)的形式，当时的表达还只是“process”这个术语，它还不是现代操作系统意义上的“进程”的概念。

　　join同步点表现为多个并行处理的进程由于某种原因不得不同步的点，也就是多个并行流程汇合的点，直到现在，在多线程编程中，这个点依然叫join。比如Java Thread的join方法以及pthread库的pthread_join函数。

　　广义来讲，join也表示诸如临界区等必须串行通过的点，减少join点的数量将会提高并行的效率。

　　我们来看看Conway论文中关于fork的原始图示：

　　僵尸进程和孤儿进程_管理用户会话连接的进程_UNIX 进程管理

　　Conway在论文中的另一个创举是，他将处理进程(也就是后来操作系统中的process的概念)以及执行该进程的处理器(即CPU核)分离了开来，抽象出了schedule层。

　　大意是说，“只要满足系统中的活动处理器数量是总处理器数量和并行处理进程的最小值即可。”这意味着调度程序可以将多处理器系统的所有处理器和系统所有处理进程分别看作是统一的资源池和消费者，执行统一调度：

　　僵尸进程和孤儿进程_UNIX 进程管理_管理用户会话连接的进程

　　在UNIX引入fork之后，这种多处理器并行的设计思想就深入到了UNIX的核心。这个思想最终也影响了UNIX以及后来的Linux，直到现在。

　　关于这个设计思想为什么可以影响UNIX这么久，我想和Conway本人的“Conway’s law”不无关系，在这个law中，他提到：

　　Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

　　真正的大牛一枚！

　　好了，fork本身的由来我们已经了解，就像做菜一样，现在我们把它放在一边备用。

　　花开两朵，各表一枝。接下来看UNIX fork的另一个脉络。

　　早期UNIX的覆盖(overlaying)技术

　　1969年最初的UNIX用一种在现在看来非常奇怪的方式运行。

　　一般的资料都是从UNIX v6版本开始讲起，那个版本已经是比较“现代”的版本了，所以很少有人能看到最初的UNIX是什么样子的。即便是能查阅到的1970年的PDP-7上运行的UNIX源码，也是引入fork之后的版本，在那之前的最原始版本几乎找不到了(你可能会说，那时的UNIX不叫UNIX，but who cares…)。

　　1969年的汤普森版UNIX超级简陋，这可以在Dennis M. Ritchie的一篇论文中见一斑：

　　The Evolution of the Unix Time-sharing System：

　　~kohler/class/aosref/ritchie84evolution.pdf

　　建议细读。

　　最初的UNIX是一个分时系统，它只有两个shell进程，分别属于两个终端：

　　UNIX 进程管理_管理用户会话连接的进程_僵尸进程和孤儿进程

　　可见其简陋。这里插叙一段关于分时系统的文字：

　　分时系统最初并不是基于进程分时的，那时根本还没有完整的进程的概念，分时系统是针对终端分时的，而操作员坐在终端前，为了让每个操作员在操作过程中感觉上是在独占机器资源，每个终端享受一段时间的时间片，在该时间片内，该终端前的操作员完全享受机器，但是为了公平，超过了时间片，时间片就要给另一个终端。

　　时间片的大小一般是十几秒到分钟级别。这个和现如今的进程调度时间片完全是两个概念。

　　就是这样，最初的UNIX为了体现分时特性，实现了最少的两个终端。注意，最初的UNIX没有fork，没有exec，甚至没有多进程的概念，为了实现分时，系统中仅有两个朴素的shell进程。

　　事实上，最初的UNIX用只有两个元素的表来容纳所有进程(显然，这看起来好笑…)，当然，这里的“表”的概念也是抽象的朴素概念，因为当时的系统是用PDP-7的汇编写的，还没有后来C语言数据结构。

　　我们现在考虑其中一个终端的shell进程如何工作。马上问题就来了，这个shell进程如何执行别的命令程序？？

　　如果说系统中最多只能容纳两个进程，一个终端只有一个shell进程的话，当该终端的shell进程执行其它命令程序时，它自己怎么办？这个问题得思考一会儿…

　　注意，不要用现代的眼光去评价1969年的初版UNIX，按照现代的眼光，执行一个程序必然要生成一个新的进程，显然这在初版UNIX中并不正确。

　　答案是根本不用产生新的进程，直接将命令程序的代码载入内存并覆盖掉shell进程的代码即可！当命令执行完后，再用shell的代码覆盖掉命令程序的代码，针对单独的终端，系统其实一直在执行下面的覆盖循环(摘自论文的Process control 章节)：

　　管理用户会话连接的进程_UNIX 进程管理_僵尸进程和孤儿进程

　　这会让很多人大跌眼镜的吧。

　　然而，在fork被引入UNIX之前，事实就是这样。一个终端上一直都是那一个进程，一会儿它执行shell的代码，一会儿它执行具体命令程序的代码，以下是一个覆盖程序的结构(图片来自《FreeBSD操作系统设计与实现》一书)：

　　管理用户会话连接的进程_UNIX 进程管理_僵尸进程和孤儿进程

　　结合上图和无聊的覆盖循环的第3)步，你会发现，这个第3)步其实就是exec的逻辑。如果你熟悉Linux内核execve系统调用加载ELF可执行文件的逻辑，你会发现，对于ELF文件而言，这里所谓的bootstrap其实就是load_elf_binary函数。

　　然而，当时毕竟还没有将这个逻辑封装成exec系统调用，这些都是每一个进程显式完成的：

　　exec逻辑是shell程序的一部分，由于它会被所有的命令程序所使用，该逻辑也被封装到了exit调用中。

　　fork引入UNIX前的表象

　　好了，目前为止，我们看完了两条线索：

　　1963年Melvin Conway提出了fork思想，作为在多处理器中并行执行进程的一个手段。

　　1969年汤普森版UNIX仅有两个shell进程，使用覆盖(overlaying)技术执行命令。

　　截止目前，我们看到的表象是：

　　UNIX fork的诞生

　　fork是如何引入UNIX的呢？

　　这还要从采用覆盖技术的汤普森版UNIX所固有的问题说起，还是看论文原文：

　　僵尸进程和孤儿进程_UNIX 进程管理_管理用户会话连接的进程

　　若要解决这些问题，很简单的方案汤普森都想到了：

　　很显然，命令程序是不能覆盖掉shell进程了。解决方案是使用“交换”技术。

　　交换技术和覆盖技术其实都是解决有限内存的多进程使用问题的，不同点在于方向不同：

　　使用交换技术解决覆盖的问题，意味着要创建新的进程：

　　UNIX需要进行改动，两个配额的进程表显然不够用了。当然，解决方案也并不麻烦：

　　管理用户会话连接的进程_UNIX 进程管理_僵尸进程和孤儿进程

　　现在，剩下唯一的问题就是如何创建新进程了！谁来临门一脚呢？

　　要讲效率，创造不如抄袭，创建新进程的最直接的就是copy当前shell进程，在copy的新进程中执行覆盖，命令程序覆盖copy的新进程，而当前的终端shell进程则被交换到磁盘保得全身。

　　覆盖和交换相结合了，UNIX离现代化更近了一步！

　　确定了copy当前进程的方案后，进一步的问题是如何来copy进程。

　　现在要说回fork了。

　　Conway提出fork思想后，马上就有了fork的实现原型(正如Conway自己所说，他只是提出了一个可能造就存在的想法，并没有实现它)，Project Genie算是实现fork比较完善的系统之一了。

　　Project Genie系统的fork不仅仅是盲目地copy进程，它对fork的过程拥有精细的控制权，比如分配多大的内存空间，copy哪些必要的资源等等。显然，Project Genie的fork是冲着Conway的多处理器并行逻辑去的。

　　还是那句话，创造不如抄袭，UNIX若想实现进程copy，有一个现成的模版就是Project Genie，但是Project Genie的fork对于UNIX太过复杂UNIX 进程管理，太过精细化了，UNIX显然用不到这些精细的控制，UNIX仅仅是想让fork出来的新进程被覆盖，而不是让它去执行什么多处理器上的并行逻辑。

　　换句话说，UNIX只是借用了fork的copy逻辑的实现，来完成一件别的事。

　　于是，UNIX非常粗暴的实现了fork！即完全copy父进程，这就是直到现在我们依然在使用的fork系统调用：

　　僵尸进程和孤儿进程_UNIX 进程管理_管理用户会话连接的进程

　　没有参数，非常简洁，显得这很优雅。

　　取了个巧，奇技淫巧：

　　UNIX fork就此诞生！

　　我们再次回顾一下UNIX fork诞生之前的景象：

　　UNIX 进程管理_管理用户会话连接的进程_僵尸进程和孤儿进程

　　每个终端单一的进程兜兜转转循环覆盖，再没有别的可能性。

　　再来看看fork诞生之后的景象：

　　UNIX 进程管理_僵尸进程和孤儿进程_管理用户会话连接的进程

　　有了fork之后，UNIX进程便可以组合出无限的可能，正式成为一个名副其实的多用户多进程现代操作系统了。fork孕育了无限的可能性(Linux上可用pstree命令观测)：

　　僵尸进程和孤儿进程_管理用户会话连接的进程_UNIX 进程管理

　　于是UNIX正式迈开了现代化建设的步伐，一直走到了今天。

　　UNIX fork-exec

　　关于exec，故事没什么好讲的，它事实上就是关于上述覆盖逻辑的封装，此后程序员不必自己写覆盖逻辑了，直接调用exec系统调用即可。

　　于是经典的UNIX fork-exec序列便形成了。

　　UNIX fork/exec/exit/wait

　　值得一提的是，fork被引入UNIX后，exit的语义发生了巨大的改变。

　　在原始的1969年汤普森版UNIX中，由于每一个终端有且仅有一个进程，这意味着覆盖永远是在shell程序和某个命令程序之间进行的：

　　然而，在fork被引入后，虽然shell执行某个命令依然是特定的命令程序覆盖fork出来的shell子进程，但是当命令执行完毕后，exit逻辑却不能再让shell覆盖当前命令程序了，因为shell从来就没有结束过，它作为父进程只是被交换到了磁盘而已(后来内存到了，可以容纳多个进程时，连交换都不需要了)。

　　那么exit将让谁来覆盖当前进程呢？

　　答案是不用覆盖，按照exit的字面意思，它只要结束自己就可以了。

　　本着自己的资源自己管理的责任原则exit只需要清理掉自己分配的资源即可。比如清理掉自己的内存空间以及一些其它的数据结构。

（编辑：开发网_运城站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!