> For the complete documentation index, see [llms.txt](https://book.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.bsdcn.org/4.3-bsd-unix-cao-zuo-xi-tong-she-ji-yu-shi-xian/di-er-bu-fen-jin-cheng/4.1.-yin-yan.md).

# 4.1 引言

进程（process）是执行中的程序。进程必须拥有内存和底层 CPU 等系统资源。UNIX 通过在一组就绪执行的进程之间调度系统资源，营造出多个进程并发执行的假象。本章描述进程的构成、系统在进程之间切换的方法，以及促进共享 CPU 的调度策略。后文各节研究进程的创建与终止、信号设施和进程调试设施。

UNIX 操作系统第一个实现动工两个月后，系统里有了两个进程，PDP-7 的每个终端各一个。到 10 个月大、仍在 PDP-7 上时，UNIX 已有许多进程、`fork` 操作和类似 `wait` 系统调用的东西。进程执行新程序的办法是把新程序读到自己身上。第一台 PDP-11 系统（第一版 UNIX）引入了 `exec`。这些系统都一次只允许一个进程在内存。后来得到一台带存储管理的 PDP-11（KS-11）后，系统改为允许若干进程同时留在内存，以减少交换。但这一改动还算不上多道程序设计，因为磁盘 I/O 是同步的。这种局面一直延续到 1972 年和第一台 PDP-11/45 系统。真正的多道程序设计，是在系统改用 C 语言重写时最终引入的：一个进程的磁盘 I/O 得以在另一个进程运行的同时进行。从那时起，UNIX 进程管理的基本结构再未改变 \[Ritchie, 1988]。

UNIX 进程在用户态或内核态下运行。用户态下，进程在机器的非特权保护模式下执行应用代码。进程用系统调用向操作系统请求服务时，切换到机器的特权保护模式，在内核态下运行。

进程使用的资源同样分为两部分。用户态执行所需的资源由 CPU 体系结构决定，通常包括 CPU 的通用寄存器、程序计数器、处理器状态寄存器和与栈相关的寄存器，以及构成 UNIX 眼中一个程序的那些内存段（正文段、数据段和栈段）的内容。

内核态资源既包括底层硬件要求的部分（寄存器、程序计数器、栈指针），也包括内核为进程执行系统服务所需的状态。这种内核状态（kernel state）包括当前系统调用的参数、当前进程的用户身份、调度信息等。UNIX 把每个进程的内核状态分放在两个数据结构中：proc 结构和 user 结构。

proc 结构包含必须始终驻留主存的信息，user 结构包含只在进程执行期间才需驻留的信息（尽管其他进程的 user 结构也可能驻留）。user 结构经存储管理设施动态分配。当前运行进程的 user 结构被映射到内核虚拟地址空间的一个固定位置，内核软件可以像引用静态 C 语言结构一样引用它。proc 结构从内核在系统启动时创建的定长表中分配。当前进程的 proc 结构通过当前进程 user 结构中的一个指针引用。

**多道程序设计**

UNIX 支持透明的多道程序设计——多个进程或程序并发执行的假象。这靠上下文切换（context switching）做到，即在进程的执行上下文之间切换。系统还提供调度（scheduling）进程执行的机制，即决定下一个执行谁。系统还提供设施，保证对进程间共享的数据结构的一致访问。

上下文切换是依赖硬件的操作，其实现受底层硬件设施影响。有些体系结构提供保存和恢复进程硬件执行上下文的机器指令，但内核使用的软件状态也必须一并切换。

上下文切换发生频繁，所以提高上下文切换的速度能显著减少花在内核里的时间，为执行用户应用腾出更多时间。上下文切换的大部分工作花在保存和恢复进程的操作上下文上，因此减少该上下文所需的信息量是产生更快上下文切换的有效途径。许多 UNIX 系统避免复制驻留进程的上下文状态，而是用存储管理硬件（若可用）把新运行进程的 user 结构映射到 user 结构的预期位置。这种映射也可以用软件经间接结构引用完成，但那样效率较低。

**调度**

公平的进程调度是一项复杂的任务，取决于可执行程序的类型和调度策略的目标。程序按其计算量和 I/O 量来刻画。调度策略通常要在资源利用与程序完成时间之间求平衡。进程的优先级根据它使用的 CPU 时间量、所占有的或执行所需的内存资源量等参数周期性重算。

UNIX 使用基于优先级的调度策略，偏向文本编辑器等交互式程序（interactive program），冷落长时间运行的批处理型作业。交互式程序往往表现为短暂的计算爆发加一段不活动或 I/O。调度策略起初给每个进程较高的执行优先级，允许它执行一个固定的时间片（time slice）。用满时间片的进程优先级被降低，而让出 CPU 的进程（通常因为做 I/O）保持原优先级。不活动的进程优先级被提高。于是，大量消耗 CPU 时间的作业迅速沉到低优先级，而大部分时间不活动的交互式作业保持高优先级，一旦就绪就能抢占长时间运行的低优先级作业。交互式作业（如文本编辑器搜索字符串）可能短暂变成计算密集型而得到较低优先级，但再次不活动时又会回到高优先级。

系统还需要一种调度策略，来对付主存不足以容纳所有待执行进程的执行上下文所引发的问题。这种调度策略的主要目标是最小化抖动（thrashing）——内存短缺到系统处理缺页和调度进程的时间超过在用户态执行应用代码的时间时发生的现象。

系统必须既检测又消除抖动。检测靠观察空闲内存量和内存请求速率：空闲页很少而新内存请求的速率很高时，系统认为自己正在抖动。消除抖动的办法是找出四个最大的进程，把其中在内存驻留最久的换出。换出进程释放的内存可分给其余进程，后者通常就能继续了。这一选择标准偏向小的交互式作业，冷落大的批作业。若抖动继续，再选出更多进程换出，直到腾出足够的内存让其他进程有效运行。最终，足够的进程完成并释放内存，被换出的进程得以回到主存运行。不过，即使内存仍不足，被换出的进程在大约 20 秒后也会被允许回来。通常抖动会卷土重来，但换入的进程不再拥有最长驻留时间，于是会有别的进程被选中换出。

调度策略偏向交互式作业组合，反映出 UNIX 最初为分时环境使用而做的设计。关于替代调度策略（批处理环境或实时系统所用者）的论文不胜枚举。这些策略通常除修改调度策略本身外，还需要改动系统。

4.2 节详述进程的状态，包括 proc 和 user 结构。4.3 节描述上下文切换的设施，以及内核上下两半都要使用的系统数据结构的访问同步。4.4 节解释前述基于优先级的调度算法的实现。4.5 节讲进程创建，4.6 节讲进程终止。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://book.bsdcn.org/4.3-bsd-unix-cao-zuo-xi-tong-she-ji-yu-shi-xian/di-er-bu-fen-jin-cheng/4.1.-yin-yan.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.