I am a beginner in operating systems and I have just learned about process switching. I have just finished reading about the concept of "interrupts". The book explains that interrupts are divided into external interrupts (hardware interrupts) and internal interrupts (software interrupts), and then explains that process switching is caused by interrupts.
What I don't understand is:
Does an interrupt always lead to process scheduling and then process switching?
If not, which types of interrupts will cause process scheduling?
For those interrupts that do not cause process scheduling, what is the state of the process after the interrupt? It cannot be in the running state. Is it in the ready state or the waiting state? (I have only learned about the 5-state model of processes). If it is in one of these two states, why doesn't it enter the process queue and trigger process scheduling?
Besides, after calling the sleep function in C, the process enters the waiting state. After the timer expires, the process enters the ready state. What I don't understand is:
I have been struggling with these questions for a long time, and I would greatly appreciate it if someone could help me answer them.
A process is a data structure that points to its thread's data structures. Threads consist of those data structures. The data structure of a thread is mostly the state of its registers and memory map (which virtual adress ranges are allocated to it).
Scheduling a thread on a core means to set the value of the registers on that core to those saved in that data structure. When an interrupt occurs, the os might call a schedule function which will look at the highest priority thread and switch the registers of a core to its saved values.
The os might decide to do that or not but this is merely a design choice. In some cases, if there are more ready threads than cores, the os might use external timers that trigger interrupts. In that case, the os must call the scheduler or at least do a checkup of the ready thread queue to make sure there are no time starved threads.
The context itself isn't all that important because it is represented by the registers of the core so it mostly comes down to design choices. In most cases, the processor has a software interface which is quite suggestive so it is always better to use that interface to its full potential to optimize performance.
On interrupt, the state of the thread doesn't change yet. The core's registers are simply changed to temporary values by hardware mechanisms. If the context on that core will change, will be a design/functional choice of the developer.
Operating-systems have focus mechanisms for applications. If the application doesn't have focus, the message that a key was pressed is not posted to its list of messages. It might also be polling mechanisms (most likely). If the thread is not polling for input, it doesn't get the message and another application might get it instead. If the message is still there, the thread will eventually get it and call a function to handle it. Scheduling delays are quite small so the thread will be get it quite soon. In human perception, it seems without delay.