multithreading - 上下文切换的步骤

Question

我被要求描述 (1) 两个不同进程之间和 (2) 同一进程中两个不同线程之间的上下文切换所涉及的步骤。

在上下文切换期间，内核将在其 PCB 中保存旧进程的上下文，然后加载计划运行的新进程的保存上下文。

操作系统可以调度同一进程中两个不同线程之间的上下文切换，使它们看起来并行执行，因此通常比两个不同进程之间的上下文切换更快。

这是否过于笼统，或者您会添加什么来更清楚地解释该过程？

Answer 1

以相反的顺序解释它们要容易得多，因为进程切换总是涉及线程切换。

单核 CPU 上的典型线程上下文切换是这样发生的:

所有上下文切换均由“中断”启动。这可能是运行驱动程序的实际硬件中断(例如，来自网卡、键盘、内存管理或计时器硬件)，或执行类似硬件中断的调用序列的软件调用(系统调用)进入操作系统。在驱动程序中断的情况下，操作系统提供了一个驱动程序可以调用的入口点，而不是执行“正常”直接中断返回，因此如果需要操作系统设置线程，则允许驱动程序通过操作系统调度程序退出准备好，(例如，它已发出信号量)。

非平凡系统必须启动硬件保护级别更改才能进入内核状态，以便可以访问内核代码/数据等。

必须保存被中断线程的核心状态。在简单的嵌入式系统上，这可能只是将所有寄存器压入线程堆栈并将堆栈指针保存在其线程控制块 (TCB) 中。

许多系统在此阶段切换到 OS 专用堆栈，以便大量 OS 内部堆栈要求不会对每个线程的堆栈造成影响。

可能需要标记发生中断状态更改的线程堆栈位置，以允许嵌套中断。

驱动程序/系统调用运行并可以通过从内部队列中为不同的线程优先级添加/删除 TCB 来更改就绪线程集，例如。网卡驱动程序可能设置了一个事件或发出信号表示另一个线程正在等待，因此该线程将被添加到就绪集中，或者正在运行的线程可能调用了 sleep() 并因此选择将自身从就绪集中删除.

运行操作系统调度程序算法来决定接下来运行哪个线程，通常是处于该优先级队列前面的最高优先级就绪线程。如果下一个运行的线程与先前运行的线程属于不同的进程，则此处需要一些额外的东西(见下文)。

为该线程从 TCB 中保存的堆栈指针被检索并加载到硬件堆栈指针中。

所选线程的核心状态已恢复。在我的简单系统上，寄存器将从所选线程的堆栈中弹出。更复杂的系统将不得不处理返回到用户级保护的问题。

执行中断返回，因此将执行转移到所选线程。

在多核 CPU 的情况下，事情更加复杂。调度器可能会决定当前正在另一个内核上运行的线程可能需要停止并替换为刚准备就绪的线程。它可以通过使用其处理器间驱动程序来硬件中断运行必须停止的线程的核心来实现这一点。除了所有其他内容之外，此操作的复杂性是避免编写操作系统内核的一个很好的理由:)

典型的进程上下文切换是这样发生的:

进程上下文切换是由线程上下文切换启动的，因此上述所有 1-9 项都需要发生。

在上面的第 5 步，调度程序决定运行一个线程，该线程与拥有先前运行的线程的进程不同。

内存管理硬件必须加载新进程的地址空间，即允许新进程的线程访问其内存的任何选择器/段/标志/任何东西。

任何 FPU 硬件的上下文都需要从 PCB 保存/恢复。

可能还有其他进程专用硬件需要保存/恢复。

在任何真实系统上，这些机制都依赖于体系结构，以上内容是对任一上下文切换影响的粗略和不完整的指南。进程切换产生的其他开销严格来说不是切换的一部分 - 进程切换后可能会有额外的缓存刷新和页面错误，因为它的一些内存可能已被调出以支持属于页面的页面到拥有之前运行的线程的进程。