Operating system 在就绪队列只有一个进程且使用循环调度的系统中是否会发生上下文切换？

在就绪队列只有一个进程且使用循环调度的系统中是否会发生上下文切换

假设孤立进程的当前cpu突发跨越循环算法的多个时间片

我的理由如下

在典型情况下，当定时器中断发生时可能发生的步骤如下

中断发生。切换到内核模式 OS将当前上下文保存到PCBsave寄存器、进程状态和当前进程的内存管理信息中 执行许多特定于体系结构的操作，包括刷新 数据和指令缓存以及TLB。 将当前进程放入就绪队列 选择要执行的新进程 从该进程的PCB加载上下文 切换到用户模式。开始执行新流程 我现在认为操作系统最好先检查就绪队列，然后检查是否还有其他进程。如果没有上下文切换，则不需要上下文切换。因此，处理计时器中断需要在用户模式和内核模式之间切换，检查就绪Q，然后切换回用户模式以恢复进程的执行

是这样吗？或者，是否进行了适当的上下文切换，包括不必要地保存孤立进程的当前状态并恢复该状态

如果后者真的发生了，有什么特别的原因吗

这种混乱是由于试卷中的一个问题引起的，这个问题涉及到在这种情况下上下文转换所花费的时间的计算。给出的答案意味着确实发生了上下文切换

---

我希望那些研究过内核代码的人能够理解这一点。因此，这个关于stackoverflow的问题。

以下来自Linux内核的代码将澄清您的疑问。在不同的时间，内核将调用调度程序来选择要运行的新进程。但调度程序可能会发现，除了当前正在运行的任务之外，没有其他任务。在这种情况下，调度器不会进行上下文切换，而只是通过不做任何操作返回

例如，我给出了Linux内核中的代码

   .........
   if (likely(prev != next)) {<-- if next and current are same, then no context switch
            sched_info_switch(prev, next);
            perf_event_task_sched_out(prev, next);

            rq->nr_switches++;
            rq->curr = next;
            ++*switch_count;

            context_switch(rq, prev, next); /* unlocks the rq */
            /*
             * The context switch have flipped the stack from under us
             * and restored the local variables which were saved when
             * this task called schedule() in the past. prev == current
             * is still correct, but it can be moved to another cpu/rq.
             */
            cpu = smp_processor_id();
            rq = cpu_rq(cpu);
    } else {
     ............

---

我并不是说这些都是确切的步骤，而且是按顺序进行的。我的意思是说，这些是可能的步骤，如果在准备好的Q中没有其他过程，那么可能不需要这些步骤。我将在我的问题中尝试更清楚地说明这一点。是的，它们来自教科书。我现在正在学习操作系统。很好！一本书将列出操作系统在一般情况下的功能。但是，正如您所提到的，实际的实现将处理角落案例。请注意，根据调度策略，即使有多个就绪进程，操作系统仍可能选择时间片刚刚用完的进程。所以这是一个非常有用的检查。您不想运行额外的代码，只是为了发现它会使系统变慢。我想接受您的答案，因为您所展示的linux代码清楚地表明，如果只有一个进程，则不会发生上下文切换。然而，我觉得代码上面的解释并不能自然地引出代码所表达的观点。这发生在我澄清问题之前。你能把你的答案编辑成非linux代码部分吗？这样我就可以接受你的答案了。欢迎提出任何修改我的问题的建议。谢谢。事实上，前面的解释有点离题。