Unit 0: 总览 | Overview¶

在正式开始核心内容的学习之前，我想先做一点说明，也算是一点关于学习操作系统的经验之谈。

操作系统概述¶

何为操作系统¶

整门课程我们需要解决的第一个问题，显然是什么是操作系统(Operating System, OS)。接下来我将从两个方面简述何为操作系统。

至此，我们从两个方面了解了什么是操作系统，现在用一句课本上的话来做总结。

The common functions of controlling and allocating resources are then brought together into one piece of software: the operating system. --Operating System Concepts (10^th edition)

操作系统的设计目标¶

现在我们知道操作系统是什么东西了，那么在此基础上我们挖掘一下，怎样才算一个好的操作系统，也就是操作系统的发展方向，而在这个过程中，我也会简单提及一些我们之后会涉及的内容，以供参考。

还有许多，例如操作系统的设计要尽可能利用硬件资源等，但并不是我们在本节想要讨论的重点，所有就掠过了。上述观点并不全面也不一定完全正确，有一大部分都是我的个人理解，请读者辨证地看待，如果有错误请务必告诉我！

操作系统的整体设计¶

计算机系统架构¶

虽然操作系统本身是软件，但是它毕竟是与硬件紧密关联的，所以我们还是会涉及到一些关于硬件的内容，这里简单涉及一些关于计算机系统架构的内容。

根据处理器的数量和组织形式，我们这里介绍三种计算机系统架构：单处理器系统、多处理器系统、集群系统。

③ 集群系统(cluster system)

集群系统通过冗余实现高可用服务，通过并行实现高性能计算，它是由多个各自独立的计算机系统作为节点(node)，通过高速通信网络互相连接形成的。

集群也分对称和不对称两种，对称集群的各个节点互相监督，而不对称的集群则存在一种类似“替补”的东西，由“替补”去监督工作中的节点，当工作中的节点出现了问题，就由“替补”来接替它的工作。

操作系统的任务执行设计¶

前面我们说过，操作系统被用来「自动化“让计算机完成一系列特定任务”」的。一开始这件事比较简单，只需要像队列一样，一个一个的执行就行，但是慢慢的随着计算机应用范围的扩大以及各种需求的出现，这种设计就不太合理了。按照发展阶段演进，我们划分出两个阶段三个设计：单道批处理系统(batch processing system)、多道批处理系统(multiprogramming batch processing system)和分时系统(time sharing systems)。

① 批处理系统阶段

最早操作系统执行任务都需要人工手动干预，但是计算机执行任务的速度与人工干预的速度相差太大，换句话来说人工速度严重限制了计算机的工作效率，于是操作系统开始出现，其中一个比较原始的实现就是批处理系统。（但不是最早，之前还有脱机处理之类的东西。）

❶ 单道批处理阶段

按照操作系统发展进程，我们首先介绍单道批处理系统(Batch Processing)。

单道批处理系统有两个关键词，“批处理”和“单道”。

“批处理”指的是，系统执行的任务是成批的，若干任务被作为一整批交付给操作系统。在具体执行过程中，操作系统自动按顺序串行(serial)执行这些任务。

而“单道”指的是，一段时间内内存中只有一道程序在运行，系统只处理一项任务，在这个任务结束之前，不会切换到其他任务。

单道批处理系统初步实现了一种“自动化”，极大减少了人工操作速度对操作系统的影响。但它存在一个非常明显的问题：由于当前任务结束之前不会切换到其它任务，所以当当前任务出现 I/O 请求时，CPU 就需要等待 I/O 完成。我们知道 I/O 操作是非常耗时的，更严重的是例如等待键盘输入这种需要人工参与的 I/O，单道批处理系统仍然没法避免这种人工操作对计算机执行效率的影响，这就导致 CPU 会长时间处于空闲状态，而让 CPU 长时间空闲这件事，是不被接受的。

❷ 多道批处理阶段

因此，为了不让 CPU 闲下来，一个符合直觉的想法就是让它先去做下一件事，就好像仓库正在收集上一个病人所需要的药品的时候，柜台可以先去处理下一个病人的请求。多道批处理系统(multiprogramming batch processing system)应运而生。

从名字上来看，多道批处理系统厉害在这个“多道(multiprogramming)”，即一段时间内内存中同时存在多个进程。

具体来说，在多道批处理系统中，当前任务发生 IO 请求时，CPU 转而去执行其它任务，以此来实现尽量让 CPU 始终在工作状态。因此，宏观上来看，多道批处理系统在一段时间内同时执行若干任务（在任务 A 完成之前任务 B 也可能开始了），我们称之为并发(concurrency)（注意，并发与并行的概念并不一致¹）；但在微观上，多道批处理系统仍然是顺序串行的，只不过区别于单道批处理系统以完整的任务作为任务单元，多道批处理系统是将完整任务按照 I/O 的发生做划分，以这些划分后的部分任务作为任务单元进行顺序串行(serial)。

我们可以用甘特图来可视化多道批处理系统的策略（一种常见的题型）。以下面的题目为例，我们来实践一下。

🌰

题面解析

现在有两个程序 A 和 B，以及两个分别独立的设备 X 和 Y，且我们只有一个 CPU：

• A 需要顺序使用如下资源：CPU: 10s, X: 5s, CPU: 5s, Y: 10s, CPU: 10s
• B 需要顺序使用如下资源：X: 10s, CPU: 10s, Y: 5s, CPU: 5s, Y: 10s

请讨论：

1. 在单道程序环境下先执行 A 再执行 B，CPU 的利用率是多少？
2. 在多道程序环境下，CPU 的利用率是多少？请给出甘特图。

在单道程序下执行，即按顺序执行 A 和 B，CPU 的利用率即实际 CPU 使用时间除以完成任务的总时间，因此：

\[ U = \frac{(10+5+10)+(10+5)}{(10+5+5+10+10)+(10+10+5+5+10)} = \frac{40}{80} = 50\% \]

---

而在多道程序环境下，我们得到如下甘特图：

蓝/CPU，绿/X，黄/Y。

要点就是纵向不能同时出现同一个资源，例如 18s 时不能 A 和 B 都用 CPU，所以 A 需要等 B 用完 CPU 再使用。

现在我们再来统计 CPU 的利用率：

\[ U = \frac{10+10+5+5+10}{45} = \frac{40}{45} = 88.89\% \]

通过这道题我们也可以发现，多道程序设计技术对 CPU 利用率的提升有多高，同时也可以从计算过程中的分母看出其对程序吞吐量的提升有多高。

多道批处理解决了单道批处理系统可能让 CPU 闲置下来的问题（当然前提是有任务让它做），提高了 CPU 等资源的利用率，增加了吞吐量，但是由于涉及到了进程的调度问题，所以实际实现会复杂一些。具体的内容我们会在进程管理这一章中详细介绍。

但是无论单道还是多道，批处理系统并不适合作为现代计算机系统。它们最大的问题就是它的交互性非常差。用户给定一定批次的任务，然后系统会自动调整这一批任务的执行顺序，最终完成这批任务，然而在这段时间里，用户就没法再用计算机做其它事情了，同时你也没法主动控制正在执行的任务，这对现代计算机来说是不可想象的。

（假设我们忽略关于屏幕显示的 I/O）试想，你希望在跑程序的时候放一个视频，但是由于你的程序还没跑完，你的视频就没法播放，突然你的程序发生了一次 I/O，CPU 转而播放已经完成 I/O 后的那部分视频，但是这个时候你的程序 I/O 很快也完成了，却需要等待缓存中的视频放完才能继续执行，这种用户体验几乎无法接受。

对于用户来说，最好能同时实现体感上的并行，也就是几件事情至少看起来要像是同时发生的，于是出现了分时系统(time sharing systems)。

多道技术出现之后，虽然计算机的表现不断提升，但是由于多道技术本身的技术特点，各个进程在未完成的情况下需要互相切换，于是一系列问题接踵而来，这些都是我们在之后的单元里详细讨论的内容。

操作系统的结构设计¶

随着操作系统的功能不断扩展、体量逐渐变大，整个操作系统软件的结构设计就越发重要了。接下来我们介绍若干设计思路。

宏内核

宏内核(monolithic-kernels)也叫单内核或大内核，它的核心思想十分简单粗暴，将所有主要功能都紧密耦合在一起，作为一个完整的整体。

宏内核带来的好处是操作系统效率极高，从操作系统的发展历程来看，主流操作系统都是从宏内核发展过来的（不过如今的主流操作系统更偏向混合系统）。

但是宏内核的缺点也是十分明显的，大量复杂的功能互相耦合，导致操作系统的维护十分困难；不仅如此，一旦某个部分出现了严重问题，整个系统都会受到影响。在这些方面，宏内核的表现不如微内核。

微内核

微内核(micro-kernels)的设计思路与宏内核相反，主张将不是必要的东西都从内核里拿出去，放到用户空间，以用户态执行。整体形成一种微内核-服务器的结构，此时内核只提供通讯、内存管理、进程管理等基本功能，也只有这些部分直接运行在内核态，作为服务器的其它功能部件则通过消息传递机制与内核互动。

由于内核只提供最基本的功能，所以内核的体积会大大减小，内核的维护和扩展也会变得更加容易，微内核-服务器的结构也使功能扩展更加容易；另外，由于内核只提供最基本的功能，所以内核自身的效率也会大大提升；不仅如此，由于各个功能之间的耦合降低，且都运行在用户态，功能之间仅使用通信建立链接，即使某个功能部件出现问题，也不会导致整个系统崩溃，相比于宏内核，系统可靠性大大提升。

操作系统的运行原理¶

中断¶

中断（广义）是贯穿现代操作系统的一个重要技术，它使得“计划之外”的事情可以及时的被告知并处理。例如，程序突然出现了致命错误，这时操作系统应该及时察觉并处理；又比如，用户在命令行输入了指令，按下了回车，操作系统应当察觉到 I/O 已经准备好了。但是我们不应当让操作系统不厌其烦地询问你有没有发生错误，又或者这个 I/O 是否就绪，这很不合理。

也就是说，我们不应当让操作系统事无巨细地去负责检查意外是否发生，而是应当提供一个上报意外的接口，让产生意外的人自行上报这些意外。在具体硬件的实现上，会有两条专门表示中断信号的线（稍候会在中断屏蔽中讲到），CPU 会在每一条指令结束后检测是否有中断发生，而在软件上就体现为每当有中断发生时，操作系统就需要去处理。由于中断的强大特性，从最早仅的处理硬件状态，到处理软件错误和作为一种类似函数的手段，中断的应用范围越来越广，它的概念随着应用范围也不断扩大。

根据中断是否由程序产生，中断可以分为外中断（狭义的中断，由硬件产生）和内中断（异常...，主要由程序产生）。这里有很多概念：instruction, exception, trap, abort, ...，这部分区分请大家自行寻找资料参考，我在这里放几个参考链接。

理想情况下，我们希望中断一旦发生就立刻被解决，但是中断处理也同样需要资源，这意味着中断也有可能产生冲突。于是，我们需要一系列机制来解决这些问题。

1. 显然，中断之间亦有区别，有的程序发生了“致命错误”这件事，显然比打印机就绪更重要，因此，中断需要分级机制，以区分中断的优先级，这样就可以在处理中断时，优先处理优先级高的中断；
2. 中断并不是随时随地都能发生的，“代理人”在走钢丝时不应当暂停去处理药品缺货这种相对无关紧要的问题，对于操作系统来说，有许多原子性的行为是不可被中断的，也有一些重要的任务是不应当被普通的中断打扰的，这就涉及到中断屏蔽问题；

需要注意，操作系统发现中断后并不是二话不说马上去处理中断的，为了保证中断处理完成后仍能继续当前任务，操作系统需要保存当前任务的状态，以便完成中断处理后恢复当前任务的状态。在 lab1 中，我们会涉及相关内容。

计时器¶

虽然看起来很不起眼，但计时器(timer)在操作系统中是一个非常重要的东西。计时器需要一个固定频率的时钟以及一个计数器，在每个时钟周期令计数器减 1，当计数器归零时产生中断，告诉操作系统定的时已经到了。

它的功能虽然基础但是十分重要，例如分时系统中就需要计数器来控制时间片的长度，又比如操作系统需要定期检查内存中的进程，以防止进程一直占用系统资源，这些都需要计时器的帮助。

特权模式¶

我们前面说过，操作系统的某些操作是危险的，有可能威胁到自身正常运作的（如与硬件直接相关的行为、控制 CPU 运行规则的行为等），而这些操作不应当被用户程序直接执行。一种简单的思路是，我们划分常规操作和危险操作，允许用户程序执行常规操作，而危险操作则需要委托专业人士代为执行。而这就是特权模式(privileged mode)的基本思路。

工业上的特权模式可能会有多种复杂的实现形式，但是我们这里只讲最简单的一种，即双模式(dual-mode)。双模式下，CPU 有两种运行模式，一种是用户态(user mode)（目态），一种是内核态(kernel mode)（管态，核心态）。Mode bit 为 0，表示 CPU 工作在内核态；mode bit 为 1 时，CPU 工作在用户态。

同时，我们将那些“危险”的指令称为特权指令(privileged instruction)，例如 I/O 控制，计时器管理，中断管理等。这些指令只能在内核态下执行，而用户态下执行这些指令时会认为这条指令不存在。

这些需求往往是可以被抽象的、被封装的。就好像「“用户”向“柜台”索要库房钥匙，以便 ta 能去库房拿缺货的货物」这件事是不合理的，我们无法控制“用户”实际拿“钥匙”做了什么，而“钥匙”的滥用又会导致“柜台”陷入危险中；但是「“用户”请求“柜台”去库房拿 ta 需要的货物」是合理的。

反过来讲，虽然「“用户”请求“柜台”去库房拿 ta 需要的货物」这个任务必须使用库房“钥匙”才能进行，但是无论如何这个“钥匙”也只会被“柜台”用来获取库房里的特定货物，而不会发生诸如“用户”带着十八车面包人把库房洗劫一空的情况。

操作系统只需要封装好一系列类似这种的需求-结果的处理方案，让用户在有需要的时候让操作系统执行这些方案，在执行当前任务的时候将控制权让渡给操作系统，操作系统完成后再还回控制权，就可以实现将特权指令隔离在内核态，同时用户程序也能完成需求。

而那么在具体实现上，这一步是通过 trap 实现的。

Transition from user to kernel mode.

系统调用¶

Examples of W&U system calls.

系统调用(system call)是系统向用户程序提供服务的一个接口，它们经常以 C/C++ 函数的形式存在，对于某些比较接近底层的任务，也可能是通过汇编编写的。

但说到底，系统调用还是相对底层的设计，通常的开发并不基于如此底层的设计展开。更常见的是利用各种抽象层级更高的 Application Programming Interface, API 进行开发。

API 是一个非常常见的概念，在我看来系统调用本身也是一种 API。API 的核心思想是让调用者只需要知道如何与被调用者交流以实现目的，而不需要关心其具体实现。这同时也暗示着，只要 API 一致，同样的程序在不同的平台上也能直接编译后运行。

显然，API 与编程语言往往是强相关的，特定编程语言在操作系统上运行也是需要一定的“环境”的，也就是我们所说的运行时环境(run-time environment, RTE)。RTE 通常包括了编译器(compilers)、解释器(interpreters)、库(libraries)和装载器(loaders)等，它们共同组成了一个完整的运行时环境。

链接器和装载器¶

The role of the linker and loader.

说了这么多，那么操作系统到底是如何执行一个程序的呢？以 C 为例，一个写完的代码需要经过编译、链接、装载三个步骤，才能成为一个在内存中的，可以被执行的程序。

简单来说，编译器首先将若干 .c 源文件编译为若干 .o 文件（这里合并了预处理、编译、汇编步骤），这些 .o 文件被称为可重定位目标文件(relocatable object file)，其存在形式为机器码；随后链接器将若干 .o 文件连带所需要的一些库文件（如 .a 文件）链接为一个可执行目标文件(executable object file)。

特别的，链接分为静态链接和动态链接两种。静态链接将库文件的代码直接合并进入最终的可执行文件，而动态链接仅仅将库文件的引用信息写入最终的可执行文件，而在程序运行时再去寻找这些库文件。

gcc -E main.c -o main.i # pre-process
gcc -S main.i -o main.s # compile to assembly code
gcc -c main.s -o main.o # assemble to object file
gcc main.o -o main      # link
./main                  # (load and) execute

可以发现，动态链接得到的可执行文件比静态链接得到的可执行文件要小不少。

引导¶

在计算机刚刚启动，操作系统还未开始运行之前，需要开机后的第一个程序——引导加载器(bootstrap loader)来一步一步地初始化操作系统。对大多数操作系统来说，bootstrap 都会被存储在 ROM 中，并且需要在一个已知的位置（否则怎么找到它呢）。Bootstrap loader 会载入更加爱复杂的，完整的 bootstrap，而包含 bootstrap 程序的分区就被称为引导分区(bootstrap partition)。

激励

评论