Why blocking system calls blocks entire procedure with user-level threads?

Question

I don't understand the following:

User-level threads requires non-blocking systems call i.e., a multithreaded kernel. Otherwise, entire process will blocked in the kernel, even if there are runable threads left in the processes.

How the kernel threads handle the blocking system calls? In the user-level threads when one thread is making a blocking system call (e.g. read) why can't other threads continue their work?

Answer 1

In the user-level threads when one thread is making a blocking system call (e.g. read) why cant other threads continue their work?

With user-level threads, as far as the OS and kernel are concerned, there is only one thread running in the process. That one thread may be doing some clever tricks (like switching from one user-thread-context to another), but it is still just a single thread that is periodically switching back and forth between several streams of instructions.

So when that single thread calls a blocking system call, that single thread has to block until that system call returns, and while it is blocked it can't do anything. One thing in particular that it can't do while blocked is switch to another user-thread-context and run some more code, because there is no way to call the switch-to-the-other-user-thread-context routine. Who would call it? The only "real" thread available is the one that is blocked inside the system call, and it can't do it because it is blocked inside the system call.

How the kernel threads handle the blocking system calls?

With kernel threads, the kernel is aware of all of the threads inside the process, because the kernel created them (on behalf of the application) and manages them directly, so the kernel can schedule any of them directly. Because of that, when thread A blocks inside a system call, the kernel/scheduler can go ahead and run thread B for a while instead, because the kernel knows that thread B exists. (Contrast this with the user-threads case, where the kernel can't schedule thread B to run, because the kernel doesn't know that thread B exists; only the user-application itself knows about the existence of the user-level threads)