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.

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