Does a context switch occur in a system whose ready queue has only one process and which uses round-robin scheduling?

Question

Does a context switch occur in a system whose ready queue has only one process and which uses round-robin scheduling?

Assume that current cpu burst of the lone process spans more than one time-slice of the round-robin algorithm.

My reasoning is as below

The steps that may take place when a timer interrupt occurs in a typical case are

1. Interrupt occurs. Switch to kernel mode
2. OS saves current context into PCB(save registers, process state and memory-management info of current process)
3. Perform many architecture-specific operations, including flushing data and instruction caches and TLB's.
4. Put current process into the ready queue
5. Choose the new process to execute
6. Load context from the PCB of that process
7. Switch to user mode. Start executing the new process

I am now thinking that the OS might as well inspect the ready queue first and check if there are other processes. If there aren't any there is no need for a context switch. Thus handling of the timer interrupt will entail switching between the user mode and kernel mode, checking the ready Q, and switching back to the user mode to resume execution of the process.

Is this what happens? Or does a proper context switch of involving the unnecessary saving of the current state of the lone process and the restoring the same take place?

If the later does happen, is there a special reason?

This confusion arose due to a question in a exam paper concerning the calculation of the time spent in context-switching in such a situation. The answer given implies that context switches do take place.

I am hoping that people who have looked into kernel code will be able to through light on this. Thus this question on stackoverflow.

Dioptometer

Answer 1

Following code from Linux Kernel will clarify your doubt. At different times, kernel will call the scheduler to select a new process to run. But it may turn out that the scheduler finds no other task but the currently running task. In that case scheduler will not undertake a "context switch" rather simply return by doing nothing.

For example, I give you the code from Linux kernel

   .........
   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 {
     ............

Aquilar

I did not mean to say that those were the exact steps and in that order. I meant to say that those were the possible steps and that they might not be needed if there was no other process in the ready Q. I will try to make that clearer in my question. And yes, they are from a textbook. I am learning about operating systems now. – Dioptometer

good! A book will list down, what the OS does in general case. But an actual implementation will take care of the corner cases, as you mentioned. Note that, based on the scheduling policy, even if there are more than 1 ready process, OS might still select the process whose time slice just ran out. So this is a very useful check. You don't want to run extra code, only to find out that it makes your system slower. – Aquilar

I want to accept your answer for the reason that the linux code you have shown clearly shows that a context switch doesn't take place if there is only one process. However I feel that the explanation above the code does not lead naturally to the point expressed by the code. This happened before my clarification about the question. Could you edit your answer(the non linux code part) so that I can accept your answer. Any suggestions to edit my question would be welcome. – Dioptometer

Thanks. Indeed the previous explanation was a little too out of context. – Aquilar