《操作系统导论》第4章：抽象：进程 - 深度知识架构

物理CPU数量极其有限（甚至只有一个），但操作系统必须满足用户和多道程序对“几乎有无数个CPU同时可用”的并发运行假象的渴望。

进程 (Process)：
- 定义：操作系统为正在运行的程序提供的基本抽象。
- 角色：它是并发执行的实体载体。进程不仅包含磁盘上的静态代码，更包含动态的机器状态 (Machine State)，如内存（地址空间）和特殊寄存器（程序计数器PC、栈指针等）。
时分共享 (Time Sharing)：
- 定义：允许资源由一个实体使用一小段时间，然后再由另一个实体使用一小段时间的技术。
- 角色：实现CPU虚拟化的核心底层方法论。操作系统通过它让多个进程交替使用CPU，从而创造出多CPU并发的假象。
上下文切换 (Context Switch)：
- 定义：停止一个进程并恢复另一个进程执行的具体动作。
- 角色：实现时分共享的底层技术手段。它通过将当前进程的寄存器内容保存到内存中，并将新进程的寄存器内容恢复到物理硬件中来实现切换。
进程列表 / 进程控制块 (Process List / PCB)：
- 定义：操作系统用来跟踪系统中所有运行程序的数据结构。
- 角色：操作系统的“记账本”。它存储着进程的上下文（寄存器状态）、当前状态等信息，是操作系统进行进程管理的物质基础。

为了解决“有限的CPU与大量的并发需求”这一矛盾，本章展现了如下的逻辑推导过程：

最初的直觉：最简单的做法是让一个程序独占CPU一直运行到结束。但这会导致严重的等待问题，且无法实现多任务并发。
初步的方案（时分共享）：操作系统采用时分共享技术，让多个程序轮流在CPU上运行一小段时间。
遇到的问题：第一，当一个程序发起慢速I/O（如读磁盘）时，如果CPU只能干等，将造成极大的资源浪费。第二，在频繁地停启进程时，如何确保程序下次运行还能“记住”之前的进度？
最终的成熟方案（引入状态模型与数据结构）：
- 为了解决I/O等待的浪费，系统将进程抽象出运行（Running）、就绪（Ready） 和阻塞（Blocked） 三种状态。当进程发起I/O时，OS将其置为“阻塞”态，并调度另一个“就绪”态的进程使用CPU。
- 为了解决进度记忆问题，系统在内存中维护了进程控制块（PCB） 等数据结构。在进程被剥夺CPU时，系统将它的寄存器上下文“快照”保存在这里；当它再次被调度时，再原封不动地恢复到硬件中。这套状态流转与现场保护机制，完美实现了可控的多任务并发。

本章首次明确提出了操作系统设计中极为重要的一对解耦概念（这种分离是一种模块化的软件设计原则）：

机制 (Mechanism - "How")：底层的“实现手段”。它为系统“如何”做某事提供答案。例如：上下文切换机制，它只负责解决如何保存和恢复寄存器状态。
策略 (Policy - "Which")：上层的“决策逻辑”。它为系统“哪个”做某事提供答案。例如：进程调度策略，它负责决定当前应该从众多就绪的进程中挑选“哪一个”来运行。

牺牲“单任务极致性能”，换取“并发性与利用率”：时分共享机制需要不断地进行上下文切换，保存和恢复寄存器（机器状态）。这不可避免地占用了原本可以用来执行用户程序的CPU周期。系统牺牲了绝对的性能开销，换取了多任务并发的假象。
牺牲“物理内存空间”，换取“全局控制力”：为了随时能够恢复进程的执行，操作系统必须在内存中长期维护进程列表、PCB结构、内核栈等。这意味着操作系统的管理数据结构不可避免地挤占了一部分本可供用户使用的物理内存资源。

策略与机制的分离（Separation of Mechanism and Policy）：将“如何做”与“做什么决定”分开，是系统架构设计中永恒的工程智慧。这使得内核开发者可以轻松更改上层调度算法以适应不同的工作负载，而无须重新编写底层那些极易出错的汇编级上下文切换机制。
状态机是驾驭异步与复杂性的利器：面对不可预知的异步事件（如网络包到达、磁盘I/O完成），操作系统将其抽象为简单的“状态转换”（如阻塞转为就绪）。这种将复杂的并发行为映射为严密状态机的做法，极大降低了系统调度的复杂度。

导师的下一步建议：

你已掌握了进程的核心抽象概念——包括进程状态模型、上下文切换和进程控制块。但进程本身并非凭空而来，应用程序需要一套系统调用来创建、操控和等待进程。下一章将详细介绍UNIX中用于进程控制的三大经典API：fork()、exec()和wait()，揭示Shell如何利用它们的组合来实现管道与重定向。