How processor is switched from user mode to kernel mode?

Question

If I understand correctly, OS runs in kernel mode and schedules processes for execution. Then we go to user mode and our code of process is executed. Then somehow we go back to kernel mode and next process is scheduled for execution.

I've read that system calls (for example: requests to access filesystem) cause CPU to go back to kernel mode. However let's say that there is this code:

for(int i = 0; i > -1; ++i);

which will take much time and it looks like that no system calls will be done here.

What does cause that processor is switched back from user mode to kernel mode? Some timeouts?

Answer 1

I will talk only about intel architecture (amd use this arch as well )) ). First of all, processes are not being scheduled. Threads are basic unit of scheduling. In modern OS (like windows, macos or linux) each thread, what is going to be running, have a standard quant of time for it. In this interval of time, thread can also wait for something (IO, synchronization primitives) and this also lead to scheduling another thread on this CPU. Also if time quant is ended, scheduler start execution of another thread. Scheduler work with timer interrupt to acomplish this with resolution about several ms.

I've read that system calls (for example: requests to access filesystem) cause CPU to go back to kernel mode. However let's say that there is this code

Not only system calls lead to raise of current privelege level on current CPU. Also interrupts and exceptions lead to this. Besides, IA32 also have several not so used methods for this, like call gates, but this isn`t used in modern OSes.

What does cause that processor is switched back from user mode to kernel mode? Some timeouts?

As I say before, in general this is timer interrupts. Basically even in they time quant thread can switch beetwen user and kernel mode many times, on hardware interrupts, on software and hardware exceptions and service calls.

Answer 2

Let's analyse your questions.

Q 1. OS runs in kernel mode and schedules processes for execution. Then we go to user mode and our code of process is executed. Then somehow we go back to kernel mode and next process is scheduled for execution.

Ans: Sometimes it's not only kernel scheduler schedules user threads for executions, it also involves schedulers in user space too. Because of this conflict, problem of priority inversion comes into picture, researchers are still working on it to find effective solution. So to schedule your thread there is no need for your thread to go to kernel mode. Scheduler in kernel will take care of it as it has list of all threads/processes running in the system. Your thread will go into kernel mode only if it requires any service from kernel apart from scheduling. So basically, to execute your thread there is no need to go to kernel, mode switching is very costly in the perspective of time and space, as kernel should store the stack frame of user thread in the kernel stack. Switching between user and kernel should be avoided as much as possible.

Q 2: I've read that system calls (for example: requests to access filesystem) cause CPU to go back to kernel mode. However let's say that there is this code: for(int i = 0; i > -1; ++i); which will take much time and it looks like that no system calls will be done here. What does cause that processor is switched back from user mode to kernel mode? Some timeouts?

Ans: Each user and kernel threads of some time quantum which is set depending on the kernel. If that thread exceeds it's execution time scheduler will preempt current running thread in the cpu and schedules another thread from the run queue. As there are number of algorithms for how to schedule the threads in CPU and different system follows different approaches suitable for the requirement. Since your code takes more time than the allocated quantum scheduler will preempt your thread and schedules other. Other thread may be user level thread or kernel thread. Hence you can see one or more kernel threads running after it preempts your thread. It is not necessary to switch to kernel threads. It all depends on the priority.

I hope I answered your question upto some extent.

Answer 3

It seems to me, that what you are asking is if your code (in a process) is running an infinite loop as shown in your example, how does the OS switch to another process? The answer is that the cpu gets interrupted by a timer which lets the OS to do its scheduling procedure. At this time, the OS scheduler may decide to context switch between the currently running process (that has the for loop in your example) and another process which is ready to be run (say an editor that is running on the same computer). In effect, the timer interrupt handler interrupts the execution of the for loop (in your example) and gives control to the kernel scheduler procedure. This is a brief description of what happens and the actual implementations are much more detailed.