1. 为什么 PA4.1 是一个分水岭从能跑到会切换如果你正在做系统能力方向的实验课程大概率会遇到 PA 系列实验而 PA4.1 往往是很多人第一次感到操作系统真的活了的节点。在前面几个阶段你写的用户程序是独占 CPU 的从头跑到尾中间没有任何打扰程序自己跑完CPU 就闲着。哪怕程序在等一个外部事件比如键盘输入、磁盘读写CPU 也只能空转等待。这在实际场景中是极度浪费的——真实操作系统里CPU 在某个程序等 I/O 的时候早就去执行另外的程序了。PA4.1 的核心目标就是打破单道程序独占 CPU的格局让多个用户程序共同驻留在内存中操作系统能够在它们之间进行切换让 CPU 利用率提上来。这个阶段你不再只是写了一个程序跑的模拟环境而是开始真正实现多道程序系统的地基。我回想自己做 PA4.1 时的感受之前做的各个部件CPU、内存、串口、磁盘像是一堆零件PA4.1 是把它们第一次串成一个会自己调度的整体。这种从量变到质变的感觉是后面做虚拟内存、进程调度、文件系统的基础。如果 PA4.1 没吃透后面几章会越来越痛苦。适合阅读这篇内容的人正在做 PA 系列实验的同学、自学操作系统想动手验证理论的人、以及在面试前想系统梳理进程切换细节的开发者。我下面会按自己的理解把 PA4.1 从原理到实现的完整链路拆开讲并附上我踩过的坑和调试思路。2. 多道程序的前提你还缺哪三块拼图在动手改代码之前建议先把 PA4.1 背后的三个概念想清楚进程是什么、上下文切换是什么、调度器解决什么问题。这三块没想明白写代码容易陷入照着抄但不知道为什么的状态。2.1 进程从一个程序实例到被管理的对象单道程序阶段你加载一个程序到内存设置好 PC 和栈指针直接 jump 过去就跑起来了。这个程序有自己的代码段、数据段、栈操作系统没有对它做任何管理。到了多道程序情况不同了。内存里同时有多个程序操作系统必须在任意时刻知道现在哪个程序在运行其他程序停在哪条指令它们的寄存器当时是什么值它们的栈里放了什么为了回答这些问题操作系统需要一个数据结构来描述每一个程序这就是进程控制块PCBProcess Control Block。PCB 里至少要有这些信息程序的标识ID当前寄存器的快照保存现场用程序的内存布局信息代码段、数据段、栈分别在哪里程序的运行状态运行中、就绪、阻塞等程序下次恢复执行时需要的 PC 值你可以把 PCB 理解为程序在操作系统里的档案袋。操作系统不直接关心程序的代码写得漂不漂亮它只关心档案袋里的信息够不够在切换时把现场完完整整地恢复回来。我在 PA4.1 中建立的 PCB 结构体大致长这样伪代码示意typedef struct { uint32_t id; // 进程 ID uint32_t status; // 运行/就绪/阻塞 uint32_t stack_top; // 内核栈顶 uint32_t entry_point; // 入口地址 // 保存通用寄存器现场 uint32_t regs[8]; uint32_t pc; uint32_t sp; } PCB;2.2 上下文切换保存现场与恢复现场的N 步走多道程序系统里CPU 在任意时刻只能执行一条指令流。当一个程序从运行变成暂时离开操作系统要做的事情就是把 CPU 当前的寄存器状态全部保存到该程序的 PCB 里然后从下一个程序的 PCB 里恢复之前保存的寄存器状态让 CPU 接着执行。这个过程就是上下文切换Context Switch。它本质上非常像我们日常生活中的接电话暂停手头工作你正在写文档电话响了你要先记住文档写到了哪一行、脑子里思路是什么接完电话再回来从那一行继续写。如果中间有另一个人想用电脑写文档你就得把文档状态完整交接给他他写完了再交接给你。PA4.1 的上下文切换通常借助内核栈来实现。每个程序进程在内核态有一个独立的内核栈切换时把当前 CPU 寄存器的值压入当前进程的内核栈再从目标进程的内核栈弹出寄存器值。这个压栈-切换栈指针-弹栈的过程是 PA4.1 最核心的汇编级操作。2.3 调度器下一个轮到谁多道程序不是说随便切而是要有一个谁下一个上 CPU的决策机制这就是调度器。PA4.1 阶段一般不会要求你实现复杂的调度算法那是后面 PA 的内容通常只需要一个简单的轮转调度Round-Robin维护一个就绪进程队列每次从队头取一个进程运行运行一段时间后放回队尾继续取下一个。这种轮转方式的好处是简单、公平、容易实现也符合先让系统跑起来的教学目标。真正要你优化调度策略的章节通常会在后续的实验中出现。我在 PA4.1 里维护的就绪队列其实就是个环形链表每次切换时从队列头取出进程运行运行完时间片后再挂到队列尾。代码量不大但能非常直观地看到多道程序在交替推进的效果。3. 我怎么在模拟器里一步步实现多道程序切换这部分是 PA4.1 的实操重点。我假设你已经有一个能跑单道程序的模拟环境接下来要做的核心改造是让 CPU 支持定时器中断让操作系统能响应中断并完成进程切换。3.1 第一步加入定时器——让 CPU 有节拍感多道程序不能靠程序自己主动让出 CPU那样碰上只顾计算的程序系统就卡死了。所以需要硬件层面的强制打断机制这就是定时器中断Timer Interrupt。我做的第一件事是给模拟的硬件增加一个定时器外设。它本质上是一个计数器按固定频率递增计数溢出时向 CPU 发送中断请求。CPU 在每条指令执行结束后检查是否有中断请求如果有就转入中断处理流程。在模拟器里加定时器时我参考了常见做法把定时器频率和 CPU 每秒执行的指令数关联起来比如每执行一定数量的指令就触发一次中断。这样整个模拟过程是确定性的便于调试。具体可以这样做在设备地址空间里分配一个定时器的内存映射地址每次 CPU 执行完一条指令就让定时器计数器加 1当计数器达到预设阈值时置位中断请求标志CPU 指令循环里检测到中断请求后保存当前 PC 和状态跳转到中断入口提示PA4.1 阶段定时器中断的触发频率不用太高我用了大约每 10000 条指令一次的中断这样每个进程能拿到足够长的连续执行时间又能在宏观上看到明显的切换效果。3.2 第二步内核态与用户态的区分——两条不同的栈多道程序最重要的架构变化是 CPU 开始区分内核态和用户态。用户程序只能运行在用户态它的特权有限不能直接访问设备、不能修改关键系统状态。操作系统运行在内核态拥有完整特权。两者之间的切换通过中断或系统调用触发。PA4.1 通常不会让你实现完整的用户态保护机制但至少要在 CPU 模型中加入模式标志并在进入中断时切换到内核模式使用内核栈。我实现的模拟 CPU 大致是// CPU 核心结构 typedef struct { uint32_t gpr[8]; uint32_t pc; uint32_t sp; // 当前栈指针 uint32_t mode; // 0用户态, 1内核态 uint32_t kernel_sp; // 内核栈指针进入内核时切换用 } CPU;用户程序运行时 sp 指向用户栈一旦发生中断CPU 自动切换到内核栈。内核栈在进程的 PCB 里记录中断处理一开始就把 user sp 保存到 PCB然后把 sp 切到内核栈地址。这个双栈设计非常重要可以有效避免用户程序的栈溢出破坏内核数据。3.3 第三步中断入口与现场保存——最不允许出错的代码中断入口是整个 PA4.1 中最关键的汇编代码。它要做的事情按顺序是保存用户态寄存器到当前进程的内核栈把用户栈指针保存到 PCB切换到内核栈调用调度函数选择下一个要运行的进程从下一个进程的内核栈恢复寄存器包括用户栈指针返回用户态继续执行我当时写入口代码时最深的体会是顺序千万不能错。保存寄存器的顺序要和恢复寄存器的顺序严格对应一个字节的偏移偏差都能导致程序瞬间飞掉。一个精简的切换入口伪代码RISC-V 风格大致是interrupt_entry: # 1. 保存寄存器到内核栈 SAVE_ALL # 2. 保存当前用户 sp 到 PCB la t0, current_pcb lw t1, [t0] # 当前 PCB 地址 csrr t2, usp # 读用户栈指针 sw t2, PCB_SP(t1) # 存到 PCB # 3. 切换 sp 到内核栈 lw sp, PCB_KSTACK(t1) # 4. 调用调度函数 call schedule # 5. 加载下一个进程的 PCB la t0, current_pcb lw t1, [t0] # 6. 恢复用户 sp lw t2, PCB_SP(t1) csrw usp, t2 # 7. 恢复寄存器 RESTORE_ALL iret这里的SAVE_ALL和RESTORE_ALL是成对的宏展开后就是一堆压栈和弹栈指令。我当时为了排查切换错误在这个宏上加了大量调试输出才最终确认某个寄存器保存位置有偏移。3.4 第四步进程加载机制——不只加载一个程序PA4.1 之前你只需要把单一程序加载到固定内存地址。现在要支持多个程序需要设计一个简单的加载规范。我采用的方案是把多个用户程序依次加载到内存中不同的地址区域然后为每个程序建立一个 PCB。我的加载流程是解析用户程序的二进制文件格式通常是自定义的简单格式把代码段、数据段搬运到约定地址初始化这个程序的 PCB设置入口地址、分配内核栈、初始化用户栈把 PCB 加入就绪队列注意用户程序里的跳转地址、全局变量地址都是编译时确定的所以加载地址必须和链接地址一致。我当时犯过一个蠢错编译用户程序时链接地址设的是 0x1000但加载时放到了 0x200000导致程序一运行就崩溃。后来老老实实把链接脚本里的地址和加载器的地址统一起来问题才消失。3.5 第五步第一个进程怎么启动多道程序系统的启动过程和单道不同。单道直接 jump 到用户程序入口就行多道需要在操作系统初始化完成后从就绪队列里取第一个进程手动构造看起来它之前被中断过的现场。我当初的启动思路是先把第一个进程的 PCB 初始化好在 PCB 里保存一组假想的被打断前的寄存器值主要是入口地址和栈指针然后直接从内核态恢复到用户态让 CPU 开始执行第一个用户程序。后续进程则等第一次定时器中断触发时才会被调度进入。这一块容易让人困惑的是为什么第一个进程不是正常启动而是恢复现场因为系统的统一切换流程就是中断-保存-调度-恢复第一个进程也不能例外。把它想成从一次假想的历史中断中恢复整个代码路径就统一了。4. 排错实录PA4.1 常见的几个深坑与排查链路PA4.1 的调试难度比前面几章上一个台阶因为出问题时往往不是程序崩溃这么直接而是多个程序在诡异状态下交替执行。我把自己踩过的几类坑写出来每一个都附上完整的排查思路希望能帮你少走弯路。4.1 坑之一程序切换后飞到随机地址这个坑的表现是系统运行几个时间片后某个进程的 PC 变成了一堆乱值程序执行到未定义内存区域模拟器报错退出。第一次遇到时我怀疑是调度器的问题把 schedule 函数翻来覆去看了好几遍没有发现逻辑错误。后来在切换入口和出口加了详细的寄存器打印观察某一次切换前后的寄存器状态变化才发现问题出在RESTORE_ALL的弹栈顺序和SAVE_ALL的压栈顺序不一致导致恢复时几个寄存器被错位赋值。排查顺序建议是先检查保存/恢复宏是否严格对称再检查 PCB 内存偏移是否和汇编里的偏移一致最后检查内核栈是否越界。这三类问题都不显眼但造成的现象一模一样。4.2 坑之二一个进程修改了另一个进程的数据这个坑出现时你的两个程序明明各自独立但 A 程序的某个变量总是被莫名修改成奇怪的值。排查很久后才发现是内核栈分配时没有为每个进程单独划分区域两个进程复用了同一段栈空间。A 进程在中断处理时压栈把 B 进程的内核栈数据覆盖了。内核栈的分配其实是个容易忽略的地方。我在 PA4.1 里为每个进程的内核栈分配了固定大小的内存区域并在 PCB 里记录了栈顶地址。这样每个进程的中断处理都有独立空间互相不干扰。4.3 坑之三中断反复触发导致死循环模拟器里定时器中断触发后如果中断处理过程中没有清除中断标志位或者清除得太晚CPU 会在处理完中断后立刻再次进入中断看起来就像系统卡死了一样。我第一次遇到这个问题时怀疑是调度算法有 bug因为画面表现为所有进程都不推进。后来打印中断触发次数发现数值异常地高才意识到是中断没有正常屏蔽或清除。解决方法是进入中断处理入口时先清除定时器中断标志并且在现场恢复完成后重新使能中断。这个顺序也很讲究——太早重新使能可能导致嵌套中断还没来得及保存完整现场太晚则可能丢失后续中断请求。4.4 坑之四用户程序的死循环无法被抢占如果你的模拟 CPU 在执行用户程序时不检查中断请求或者检查中断请求的位置在长指令内部而不是指令边界就会出现用户程序死循环系统完全无响应的问题。我当时是在模拟器的指令执行循环里每条指令开始之前检查中断请求标志。这样才能保证在指令边界及时响应中断。如果你把中断检查放在了指令内部或者放在了某个特定指令之后就可能出现延迟响应甚至不响应的情况。4.5 我的调试方法论把模拟器当显微镜PA4.1 阶段的调试我强烈建议你能加日志就加日志。至少要有每次进程切换时的日志哪个进程让出 CPU、哪个进程获得 CPU、当时的 PC中断触发日志触发时刻、中断类型、当前进程 ID寄存器快照日志切换前后关键寄存器变化有了这些日志你可以用一个自动化脚本来验证每个进程是否按照时间片轮流获得 CPU每个进程的 PC 是否在合理范围内推进。我甚至写过一个简单的统计脚本统计每个进程运行的时间片数量确认没有进程被饿死。另一个很实用的技巧是把时间片设得极大比如一个进程可以运行 100 万条指令才切换这样你在调试单步的时候可以清晰地看到单个进程的执行过程不受频繁切换干扰。确认单进程执行没问题后再把时间片调小测试切换逻辑。5. 从 PA4.1 可以顺手学会的优化思路PA4.1 是很多扩展实验的起点做完之后你可以顺手做几个小实验看看多道程序系统还能怎么改进。这些改进即使不在课程要求里也能帮你更深刻理解操作系统。5.1 进程状态机补全PA4.1 通常只需要就绪和运行两个状态。你可以尝试增加阻塞状态模拟用户程序请求外部设备时主动让出 CPU 的行为。这个扩展需要引入等待队列并且让调度器从就绪队列 等待队列中正确选择。做完之后你对进程状态转换会有更直观的理解。5.2 内核栈与用户栈的独立验证PA4.1 强调用户态和内核态使用不同栈但很多同学包括我其实没有认真验证过内核栈是否真的被正确隔离了。你可以写一个测试程序让用户程序故意把用户栈充满数据然后触发系统调用看内核代码是否受影响。这个测试能验证你的双栈设计是否可靠。5.3 改用抢占式调度的时机PA4.1 实现的是基本的时间片轮转调度。你可以试验不同长度的时间片对系统整体吞吐量、进程响应速度的影响。把时间片设小进程切换会更频繁响应更快但开销更大时间片设大开销小但响应变慢。这种用实验数据理解理论的体验比背结论要深刻得多。6. 做完 PA4.1 后我对操作系统的理解发生了哪些变化PA4.1 做完后我复盘时最大的感触是操作系统不是多出来的东西而是被逼出来的东西。写单道程序时你不需要进程概念不需要 PCB不需要调度器——因为只有一个程序在跑不需要管理。可一旦有多个程序要共享 CPU共享内存共享外设你就被迫发明管理它们的东西。这些管理机制组合起来就是操作系统的内核。这个视角帮我重新理解了课程里很多抽象的术语为什么进程要有状态因为程序在执行过程中确实会处于不同的境遇——运行中、就绪等待、阻断等外设。为什么要有上下文切换因为 CPU 只有一个程序有很多个交接时必须完整传递现场。为什么调度算法值得研究因为不同场景下谁先用 CPU的决策会直接影响用户感知。多道程序的价值不仅仅在于让 CPU 更忙更在于它让我们第一次意识到计算机系统不只是一个执行程序的机器而是一个需要统筹资源的管理者。PA4.1 给了你一个亲手构建管理者的机会哪怕它很小、很简化但从无到有的过程远比你背十遍课本来得深刻。如果你正在做 PA4.1我建议你不要急着把所有代码写完美再跑而是先让一个极其粗糙的版本跑起来——哪怕只有两个程序、每次切换打印一行日志也行。先看到切换发生了再逐步完善细节。系统代码和其他代码最大的不同是它本身是活的一旦你把它的生命力激活后面的路就会越走越顺。