1
votes

I have been trying to understand the user level and kernel level threads better but I feel I am completely lost. I framed few questions to clarify my doubts.

I read somewhere that threads can be supported in the following ways.

  1. Completely managed at user level. Kernel is unaware of it. When one thread gets blocked, even though there are runnable threads, they do not get a chance to run

  2. Kernel threads: Scheduled by kernel; In kernel's view, it is like a process only, but a lightweight process. Each such thread is a schedulable entity. In this case, are there any support needed from the user level library? Are there any scheduling happens at the user space? Do any systems use such thread models?

  3. User threads on top of kernel threads: Here kernel is aware of the threads that are running in the user space. So user level threads can make blocking calls and kernel can run other threads from the same process. So in this case, do we have two different schedulers - one in kernel level and one in user level? If so, What is the purpose of user level scheduler? Also, I read that, if one user level thread blocks, then the kernel thread on which the user thread was running, is also blocked; And if that kernel thread was the only thread that was running on a processor, then the processor becomes unusable. If the user level thread is blocked, why can not the kernel pick another user level thread and run it with the same kernel thread? They say that the solution is, to have multiple kernel threads and context switch between them. In this case, if all the kernel threads are blocked (because the corresponding user level thread blocks), then none will be running in the system. Instead of this, why can not we change the association i.e., change the user level thread that runs on a given kernel thread? In this case, we can avoid the need to create multiple kernel threads right?


I know some of these questions might not make sense. But I read a lot of materials and got confused enough. Please clarify. I would greatly appreciate if you can suggest any good online material/research paper/text books that talk about the basics of user/kernel threads and the varying scheduling policies.

1

1 Answers

0
votes

2.No, if threads are managed by the kernel, they're managed by the kernel and not any user-level code. Windows is an example of such an OS.
3.You don't have to have 2 different schedulers to schedule kernel and user threads. You may, but it's not necessary. The CPU does not necessarily become unusable if a kernel or user thread blocks. If there are other threads to run, the CPU can pick them. Unless, of course, it's a multi-processor system and other threads are bound/affinitized to other CPUs. Associating a user thread with a different kernel thread is usually complicated. Normally, there's very little distinction between kernel and user threads that are on top of kernel threads. In the kernel's view they're mostly the same kind of thing.

I don't know where you've read all that, what OS that was, but that design seems to be very restrictive and inefficient to me.