上下文切换和调度 [英] Context switching and scheduling

问题描述

我有以下疑问，每当由于某个系统调用而发生任务切换时，调度程序会将cpu寄存器存储在其中（比如任务A的TCB）（任务控制块）并恢复cpu寄存器以执行其他任务（任务B）从自己的TCB开始运行。



我的疑问是，在中断期间会发生什么，其中存储了中断任务的cpu寄存器。我的理解是它存储在中断堆栈中（IRQ堆栈，让我们拿ARM）。因此，如果寄存器存储在IRQ堆栈中，并且如果中断导致调度程序切换到新任务（我的假设是调度程序在定时器中断上下文（系统自动收录器）中运行），那么调度程序如何存储被中断的任务cpu寄存器，因为它存储在IRQ堆栈中。只有当中断处理程序返回时，才会从IRQ堆栈中恢复cpu寄存器，并且中断的任务继续执行。但是如果中断导致新任务的调度（比如定时器中断，导致调度程序选择新任务），中断处理程序如何返回？旧任务如何恢复？如何恢复旧任务寄存器？我有点困惑。任何人都可以帮我理解上面的情况吗？

解决方案

中断的行为类似于调用：代码被中断的当前地址存储在堆栈中;寄存器被压入堆栈，还有标志;它全部由中断返回指令恢复，因此在中断返回时继续执行。



这是单线程系统中会发生的情况。对于多线程，抢占发生在某些中断上，最典型的是定时器中断。从中断任务的角度来看，控件返回到中断点，正如我在前一个字符中所解释的那样。系统范围的图像可能更复杂：调度程序将控制转移到某个其他线程，也就是之前中断的位置。因此，对于每个线程，它看起来都是透明的：它总是在被中断的点上获得控制权，但是一个或多个其他线程可以在给定的中断和获得控制之间获取时间片。



用简单的词语解释并不容易，但如果你绘制图表和/或编写一些代码或pseuto-code，就可以清楚地说明。所涉及的低级机制和CPU指令在不同的处理器体系结构中是不同的。值得注意的是，它与Intel x86 *和IE-32 / IE-64架构的实模式和保护模式非常不同。

-SA

I have the following doubt, whenever a task switch happens due to some system call, scheduler will store the cpu registers in its(say task A's TCB)(Task control block) and restore the cpu registers for the other task(task B) which is goiong to run from it own TCB.

My doubt here is, what happens during interrupt, where the cpu registers for the interrupted task is stored. My understanding is that it is stored in Interrupt stack(IRQ stack, let's take ARM). So if the registers are stored in IRQ stack, and if the interrupt results in the scheduler to switch to new task(my assumtion is that scheduler runs in timer interrupt context(system ticker)), how the scheduler store the interrupted task cpu registers, since it is stored in the IRQ stack. Only when the interrupt handler returns, then only the cpu registers are restore from the IRQ stack and interrupted task continue to execute. But if the interrupted results in scheduling of new tasks(say timer interrupt, which results in scheduler selects a new task), how the interrupt handler returns? how the old task resumes? How the old task registers are restored? I am bit confused . can anyone please help me to understand the above scenario?

解决方案

The interrupt behaves similarly to the call: the current address where the code was interrupted is stored on stack; the registers are pushed onto stack, and also the flags; it all is restored by the interrupt return instruction, so the execution continues at the point where it was interrupted.

This is what would happen in the single-thread system. With multiple thread, preemption happens on some interrupt, most typically, timer interrupt. From the standpoint of the interrupted task, the control is returned to interrupted point, as I explained in the previous character. System-wide picture can be more complex: the scheduler transfers control to some other thread, also at the point where it was interrupted before. So, for each thread it looks transparent: it always gets control at the point it was interrupted, but one or more other threads can take their time slices between the given interrupt and getting control.

It's not so easy to explain in simple words, but can be made clear if you draw the diagram and/or write some code, or pseuto-code. The low-level mechanism and CPU instructions involved is different in different processor architecture. Notably, it's very different for real-mode and protected mode of Intel x86* and IE-32/IE-64 architectures.

—SA

这篇关于上下文切换和调度的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！