linux - 反对用户级线程的最具破坏性的论据

Question

我正在阅读《现代操作系统》一书中有关用户空间线程的部分。它指出:

Another, and probably the most devastating argument against user-level threads, is that programmers generally want threads precisely in applications where the threads block often, as, for example, in a multithreaded Web server. These threads are constantly making system calls. Once a trap has occurred to the kernel to carry out the system call, it is hardly any more work for the kernel to switch threads if the old one has blocked, and having the kernel do this eliminates the need for constantly making select system calls that check to see if read system calls are safe. For applications that are essentially entirely CPU bound and rarely block, what is the point of having threads at all? No one would seriously propose computing the first n prime numbers or playing chess using threads because there is nothing to be gained by doing it that way.

我对粗体文本特别困惑。 1.既然这些是用户空间线程，那么内核如何“切换线程”呢？ 2.“让内核做这个”，这里的“这个”是什么意思？

我认为行为是这样的: 1. 进行“select”调用，发现下面的系统调用是一个阻塞调用。 2. 然后用户空间线程调度器进行线程切换并执行另一个线程。

Answer 1

出于某种原因，大学坚持使用令人困惑且有时毫无意义的操作系统教科书。

首先，这里描述的内容完全是系统特定的。在某些操作系统上，同步系统调用将阻止所有线程。并非所有操作系统都是如此。

其次，用户线程是穷人的做事方式。过去，用户线程的出现是因为没有操作系统支持。有些人认为用户线程比内核线程更“高效”(理论上，库可以比内核更快地切换线程)，但这在实践中完全是胡说八道。用户线程已完全过时，强制开发人员使用它们进行线程处理的系统也已过时。即使像 VMS 这样的旧系统也有内核线程。

在现代操作系统类(class)中，“用户线程”应该是侧边栏或历史脚注。

本质上，你的书试图在不存在的情况下进行一场辩论。这就像二战后美国陆军将谢尔曼坦克与黑豹进行比较的评估一样。他们谈论诸如谢尔曼移动舒适的座椅，试图使两者听起来具有可比性之类的事情，而实际上，谢尔曼已经过时了，甚至与黑豹不在同一级别。

1.Since these are user space threads, how can the kernel do a "switch threads"? 2. "having the kernel do this" , what does "this" here mean?

他们似乎暗示线程在进行系统调用时将阻塞进程。当发生这种情况时，操作系统将进行上下文切换。在这种情况下，操作系统无论如何都会“线程切换”到另一个进程。他们试图引导您得出的[正确]结论是，此开关消除了用户线程据称减少的开销。

I thought behaviors are like: 1. "select" call is made, and find following system call is a blocking one. 2. Then the user space thread scheduler makes a thread switching and execute anohter thread.

让我以用户线程实现为例，该实现没有被阻塞系统调用完全阻塞。

1. 该库为线程切换设置了一个计时器。
2. 线程开始或恢复执行。
3. 线程创建阻塞系统服务(例如 select)。
4. 操作系统将进程切换为系统服务处理的一部分。
5. 计时器响起。
6. 进程再次变为当前进程，操作系统调用库中的计时器处理程序。
7. 库安排另一个线程执行。

您面临的问题是，阻塞系统服务通常会在其处理代码中包含触发上下文切换的部分。因为系统不知道线程(否则它将使用内核线程)，所以调用此类阻塞服务的线程将通过代码。

即使进程可能具有可执行的线程，操作系统也无法使它们执行，因为操作系统知道它们，因为它们是由进程中的库管理的。