上下文切换的思考

为什么要使用异常、中断来进行上下文切换？

现代的处理器 pc 中一般保存的是下一条待执行指令的地址。上下文切换需要【改变执行流】，不管中间有怎样的过程，最终都会反映到 pc 值的变化上。

那么我们可以如何改变 pc 的值？

简单的思考后我们会发现子函数调用、子函数返回、中断、异常都有改变 pc 值以及改变栈帧的能力。虽然子函数的调用与返回拥有改变 pc 值的能力，但是它们无法做到动态切换栈帧，也没办法在任意的断点进行上下文切换，毕竟子函数的调用返回都只在【固定的位置】发生。

中断与异常却【没有】这样的限制。对于中断而言，它可以在任务函数中的任何一条指令执行完成后进行响应，而异常作为一种同步的方式，可以在任务函数中主动调用来进行触发。

在实际的上下文切换实现中我们确实需要考虑使用异常服务程序来进行上下文切换以及在中断中进行上下文切换的问题。

一个任务一个本地化现场

单就函数而言，函数调用前后内容不变的寄存器称为调用者保存寄存器，不需要再编写额外的代码进行压栈弹栈。对于任务之间的切换却需要保护这些寄存器。

每一个任务都是独立的现场，这个现场是所有可能使用到的通用寄存器与处理器状态寄存器，这些是所有任务共享的资源，任务不执行时由任务栈保存这些本地化资源的值，执行时由这些本地化资源单独建立起不同任务的执行环境来执行。

这样的过程与多线程中的某些机制有类似之处，需要解决共享资源的本地化问题。这里也存在着临界区，保存现场与恢复现场其实都是在临界区内执行的！

多线程为我们提供了一套并行执行程序的流程，多任务为我们提供了一套并发执行程序的流程。可能多线程也可以算作是一套并发执行程序的流程，可在多核心 cpu 中它的表现更好！

对共享资源的进一步思考

我这里提到的多线程与多任务都共享了计算机的硬件资源，这给操作系统中多线程与多任务功能的实现带来了新的挑战。

系统设计者需要考虑同步的问题，通过使用同步机制来保证共享的硬件资源状态对单个程序具有一致性，这算是一大难题。

以前我对这一过程所要保护对象的认识多停留在共享的数据结构之上，现在我看到了更为底层的共享，这就是程序执行真正依赖的 cpu 硬件环境。这也说明这样的过程是可以进一步扩展的，它体现在操作系统设计的不同层次中。