1
votes

IF you take the scenario where a thread is being executed on the CPU and along comes an interrupt a programmable timer interrupt. So my understanding is the CPU stops what it's doing with the current executing thread and now begins executing the interrupt service routine associated with the interrupt. Now once the ISR has completed executing its code the dispatcher loads the context of the next (highest priority) thread which is to execute on the CPU. Now in both cases the CPU must begin executing again, the ISR and the next thread. So my question is what mechanism or CPU instruction tells the CPU to begin executing again at the new instruction address of each the ISR and the next highest priority thread ? If my understanding is incorrect would someone please make the correction as required ? Thank you.

1
CPUs don't really know about threads; it's the OS scheduler that decides whether to return to the saved user-space context of one task or another.Peter Cordes

1 Answers

2
votes

Now in both cases the CPU must begin executing again, the ISR and the next thread. So my question is what mechanism or CPU instruction tells the CPU to begin executing again at the new instruction address of each the ISR and the next highest priority thread ?

The CPU never stops executing code. It does not know and does not care what a operating system thread is. If it is executing code in a user mode application and an interrupt occurs it will switch from user mode to kernel mode, save on the stack some information about the interrupt, and execute the appropriate interrupt handler, as set by the operating system. It is the responsibility of that interrupt handler to handle the interrupt and resume execution from where it was interrupted. Returning from an interrupt is done with a special instruction: IRET, IRETD, or IRETQ (assuming an x86 CPU). In all this time the CPU is always executing code and it never stops (assuming no HLT instruction was executed). If the operating system scheduler decides that another thread must run, it makes the necessary changes so that another operating system thread will run, but the CPU knows nothing about what the scheduler does.

Since you tagged this with Windows, this blog post might provide some extra information. For generic details you can always check osdev.