为什么阻塞系统调用会阻塞用户级线程的整个过程? [英] Why blocking system calls blocks entire procedure with user-level threads?

问题描述

我不理解以下内容:

用户级线程需要非阻塞系统调用，即多线程内核.否则，即使进程中剩下可运行的线程，整个进程也会在内核中阻塞.

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?

推荐答案

在用户级线程中，当一个线程构成阻塞系统时 调用(例如读取)为什么其他线程无法继续工作?

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.

因此，当单个线程调用阻塞的系统调用时，该单个线程必须阻塞，直到该系统调用返回为止，而在阻塞时它无法执行任何操作.在 specific 中，它在被阻止时无法执行的一项操作是切换到另一个用户线程上下文并运行更多代码，因为无法调用切换到其他线程的方法.用户线程上下文例程.谁会称呼它?唯一可用的真实"线程是在系统调用中被阻止的线程，因为在系统调用中被阻止，所以它无法执行该操作.

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?

对于内核线程，内核知道进程内的所有线程，因为内核(代表应用程序)创建了它们并直接对其进行管理，因此内核可以直接调度它们中的任何一个.因此，当线程A在系统调用中阻塞时，内核/调度程序可以继续运行线程B一段时间，因为内核知道线程B存在. (这与用户线程的情况相反，在这种情况下，内核无法安排线程B的运行，因为内核不知道线程B的存在；只有用户应用程序本身才知道用户级线程的存在. )

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)

这篇关于为什么阻塞系统调用会阻塞用户级线程的整个过程?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！