Can context switch happen without interrupts?

Question

In my OS textbook it is written:

Interrupts cause the operating system to change a CPU core from its current task and to run a kernel routine. Switching the CPU core to another process requires performing a state save of the current process and a state restore of a different process. This task is known as a context switch.

From this, it is pretty much understandable that interrupts can cause context switching. Are interrupts the only way of context switching, or can we switch contexts even without the interrupts? And is context switching only valid in the context of threads and processes?

Answer 1

Context switches can be performed by the operating system when kernel code is running in a privileged processor mode, independently of how it got there.

As written in your book, this may happen when an interrupt arrives at the CPU core. The core then changes to a privileged mode and runs the appropriate interrupt handler the kernel installed. The kernel then may decide to switch to the context of another process/thread or hand control back to the interrupted task. Interrupts are the only way to involuntarily swap out a running task.

Another way that can cause a context switch is when a task performs a system call (e.g. sched_yield, recv, etc.) sched_yield directly asks the kernel to yield the CPU to another task, but e.g. recv can cause also a context switch if the system still has to wait for data to be received.

And is context switching only valid in the context of threads and processes?

As context switching saves the state of one task and restores that of another task and tasks are usually called "threads" and groups of threads that have some common state are usually called "processes", it's fair to say that context switching on operating system level is always done between threads and/or processes. However the terminology is sometimes reused for e.g. green threads in userspace.

Answer 2

The cpu context (regs, some tables) changes as a result of switching process. Going from user mode to kernel mode is not a complete context switch as only few regs are changed: the same process is still running but, running some code implemented by the kernel like an i/o or page update, etc. Now, the complete context is changed as a result of an interrupt (timer, fault, hw, ) or by the kernel when a process goes blocked after requestingg an i/o.

Answer 3

Context-switches only occur when… the context (think of not only cpu registers' value but also page tables, open files handlers, permissions… ) needs to be… switched (changed for others).

Apart from interrupt handling that you already understood, this concept is only known in the context of multiprocessing since in the case of single processing… there is always a unique context.

System calls do not trigger context-switch per se since the kernel, when executing the procedure needs to run in the calling process context and moreover, after completion, the execution is likely to resume on the next instruction of the calling process as if whatever ordinary subroutine had been called.
However, in some cases (blocking read on some opened descriptor for example), the kernel is aware that execution should not resume in the calling process. (since it should instead be waiting for some event to occur)
At the right opposite, chances should be offered for the scheduler to schedule the process out and schedule another one in. Context will necessarily be changed (to the benefit of the scheduled-in process context) => a Context-switch must happen.

To sum up with, a context-switch will systematically occur immediately after some IRQ fires (since the IRQ handler is never executed on behalf of whatever process) whereas a context-switch might occur at some point of the execution of some system call depending on possible scheduling opportunities.