@awu that's my understanding as well – would appreciate a correction if I'm wrong here! This is the chain of events that happens when the CPU scheduler decides to switch contexts, so we're interrupting the previous tasks that our CPU had.
@awu, @superscalar. As someone who's worked with OS's (CS140 / Solar Car), I might be able to explain what goes on behind the curtain:
In a time-sharing OS (like Unix), what happens (in the single-core case) is that the OS has a list of processes it needs to run. Every t milliseconds, a "timing interrupt" goes off. Once this happens, the CPU sees that the interrupt occurred and goes into its "interrupt handler". In the interrupt handler (which is software in the OS), the OS can make a decision for what process to schedule next.
By "Scheduling Next" what is usually done is the "state" (execution context) of the current process is saved to disk / memory and the state of another program is restored.
Without the interrupt, there wouldn't be an easy way for something as low-level as the OS to figure out when it's time to move out a process and move in a new one.
Hope this helped explain some stuff :)
Can the OS directly dictate which CPU context to place a program? Thats a bit over-powered... but maybe this is how Linux handles affinities.
@Martingale - I think the OS can directly dictate which CPU context to place the program in incase more than one become available for the next task at hand. Various scheduling mechanisms, to begin with - can be round robin, first-come first-serve, etc. Linux for instance uses a Completely Fair Scheduling (CFS) algorithm, which is an implementation of weighted fair queueing (WFQ).
(https://www.geeksforgeeks.org/completely-fair-scheduler-cfs-and-brain-fuck-scheduler-bfs/)
Please log in to leave a comment.
Why is the interrupt necessary? Is it because we'd switch from one context to another?