Why does the OS require / support kernel threads?
Below are the three thread models that I have encountered. Based on these below 3 architectures it became clear to me that there is also something called a kernel thread besides the user thread which is introduced as part of POSIX.1C
This is model 1-1
This is model N-1.
This is a hybrid model.
I have a lot of questions about SO for kernel threads. This is a more relevant link for clarification.
At the Process Level For every user process loaded by the Linux bootloader (say), the Kernel does not allocate a corresponding kernel process to execute machine instructions that originate in the user process. Only prompting the user to execute kernel mode when it requires a facility from the kernel module [eg malloc () / fork ()]. User process scheduling is done by the OS scheduler and assigns the CPU core.
For example, a user process does not need kernel run mode to execute the command
a=a+2;//a is my local variable in a user level C function
My question is:
1) So what is the purpose of a kernel level thread? Why does the OS need to support a kernel thread (optional) for the corresponding user thread of a user level process? Does the user mode programmer have any control over choosing any of the three thread models for a given user process through programming?
After I understood the answer to the first question, one of the relevant additions,
2) Is the kernel thread actually scheduled by the OS scheduler, but not the user thread?
source to share
I think the use of the kernel dictionary stream is a little bit wrong in these numbers. I know the numbers from a book about the operating system (design), and if I remember correctly, they refer to how the operating system is scheduled to work. In the figures, each process has at least one kernel thread assigned by the kernel.
Model N-1 shows several threads of user land that are not known to the kernel at all, because the latter has scheduled the process (or, as it called in the figure, one kernel thread) only. Thus, to the kernel, each process is a kernel thread. When a process is assigned a slice of CPU time, it launches several threads itself, scheduling them as it sees fit.
In model 1-1, the kernel is aware of user land threads, and each thread is considered for CPU timing by the scheduler. Therefore, instead of scheduling the entire process, the kernel switches between threads within processes.
Hybrid model combines both principles, where light processes are actually threads known to the kernel and scheduled to run. Also, they implement threads, the kernel does not know and does not assign a time processor in the user's country.
And now, to be completely confused, there is actually a real kernel thread in Linux. But as far as I understand the concept, these threads are only used for operations in kernel space, for example. when kernel modules need to do something in parallel.
source to share
So what is the purpose of a kernel level thread?
Provide a vehicle for assigning a set of OS exposed resources. The set always includes the execution of the CPU code on the kernel. Others can include disk, NIC, KB, mouse, timers, which can be requested with system calls from the thread. The kernel manages access to these resources as they appear and resolves conflicts between resource conflicts, for example. requesting KB input when none are available will remove the CPU execution from the thread until KB input is available.
Why do we need a kernel thread (optional) for the corresponding user user level process thread?
Without a thread at the kernel level, the user thread will not be able to get execution - it will be dead code / stack. Note that on Linux the concept of threads / processes can get a little confusing, but the fundamental unit of execution is nevertheless a thread. A process is a higher-level construct whose code must be run by at least one thread (for example, the one that is loaded by the OS loader to run code at the entry point of the process when it is first loaded).
Does the user mode programmer have any control when choosing any of the above three thread models for a given user process through programming?
No, not without syscall, which means exiting user mode.
Is the kernel thread actually scheduled by the OS scheduler but not by the user thread
Yes - that's the only thing that gets the ability to execute when it can use it, perform a delete if it can't, and expose a preemptive CPU deletion if the OS scheduler requires it for something else.
source to share