suubai
suubai

Reputation: 3

The relationship between interrupts and process scheduling

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:

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.

Upvotes: 0

Views: 692

Answers (1)

user123
user123

Reputation: 2884

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.

Upvotes: 0

Related Questions