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

Question

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

假设单个进程的当前cpu突发跨越循环算法的多于一个时间片.

我的推理如下

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

1. 发生中断.切换到内核模式
2. OS将当前上下文保存到PCB中(保存寄存器,当前进程的进程状态和内存管理信息)
3. 执行许多特定于体系结构的操作,包括刷新数据和指令缓存以及TLB.
4. 将当前进程放入就绪队列
5. 选择要执行的新流程
6. 从该过程的PCB加载上下文
7. 切换到用户模式.开始执行新进程

我现在认为操作系统可能首先检查就绪队列并检查是否有其他进程.如果没有,则不需要上下文切换.因此,定时器中断的处理将需要在用户模式和内核模式之间切换,检查就绪Q,并切换回用户模式以继续执行该过程.

这是怎么回事？或者是否进行了适当的上下文切换,包括不必要地保存单个进程的当前状态并恢复相同的进程？

如果后来确实发生了,有特殊原因吗？

这种混淆是由于试卷中有关计算在这种情况下上下文切换所花费的时间的问题.给出的答案意味着确实发生了上下文切换.

我希望看过内核代码的人能够通过这个来解决这个问题.因此这个问题在stackoverflow上.

Answer 1

以下来自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 {
     ............