multithreading - 用户级线程的好处

Question

我在看用户级线程和内核级线程之间的区别，我基本了解。
我不清楚的是实现用户级线程的意义。

如果内核不知道单个进程中存在多个线程，那么我可以体验到哪些好处？
我已经阅读了几篇文章，指出只有在此类线程不执行阻塞操作(这会导致整个进程阻塞)时，才建议使用线程的用户级实现。

话虽如此，考虑到它们不能利用多个处理器和独立调度，所有线程的顺序执行和它们的“并行”执行之间有什么区别？

对先前提出的问题(类似于我的)的回答类似于:

No modern operating system actually maps n user-level threads to 1 kernel-level thread.

但是由于某些原因，网上很多人表示用户级线程可以 从不利用多个处理器。

请你帮我理解一下好吗？

Answer 1

我强烈推荐Modern Operating Systems 4^th Edition由 Andrew S. Tanenbaum (主演 debate about Linux 等节目；也参与:Linus Torvalds )。花费一大笔钱，但如果你真的想知道一些东西，这绝对是值得的。对于热心的学生和绝望的爱好者来说，这很棒。

你的问题得到解答

[...] what's not clear to me is the point of implementing User-level threads at all.

阅读我的帖子。我敢说，它很全面。

If the kernel is unaware of the existence of multiple threads within a single process, then which benefits could I experience?

阅读下面的“缺点”部分。

I have read a couple of articles that stated that user-level implementation of threads is advisable only if such threads do not perform blocking operations (which would cause the entire process to block).

阅读“缺点”中的“不与系统调用协调”小节。

所有引用均来自我在此答案顶部推荐的书，第 2.2.4 章“在用户空间中实现线程”。

好处

在没有线程的系统上启用线程

第一个优点是用户级线程是一种在没有线程的系统上使用线程的方法。

The first, and most obvious, advantage is that a user-level threads package can be implemented on an operating system that does not support threads. All operating systems used to fall into this category, and even now some still do.

无需内核交互

另一个好处是切换线程时的开销很小，而不是切换到内核模式、做东西、切换回等等。更轻的线程切换在书中是这样描述的:

When a thread does something that may cause it to become blocked locally, for example, waiting for another thread in its process to complete some work, it calls a run-time system procedure. This procedure checks to see if the thread must be put into blocked state. If, so it stores the thread’s registers (i.e., its own) [...] and reloads the machine registers with the new thread’s saved values. As soon as the stack pointer and program counter have been switched, the new thread comes to life again automatically. If the machine happens to have an instruction to store all the registers and another one to load them all, the entire thread switch can be done in just a handful of in- structions. Doing thread switching like this is at least an order of magnitude—maybe more—faster than trapping to the kernel and is a strong argument in favor of user-level threads packages.

这种效率也很好，因为它使我们免于繁重的上下文切换和所有这些事情。

单独调整的调度算法

此外，因此没有中央调度算法，每个进程都可以有自己的调度算法，并且在选择的多样性上更加灵活。此外，“私有(private)”调度算法在从线程获取的信息方面更加灵活。 信息的数量可以手动和每个进程进行调整，因此它非常细粒度。 这是因为，再一次，没有中央调度算法需要满足每个进程的需求。它必须非常通用，并且必须在每种情况下都提供足够的性能。用户级线程允许极其专业的调度算法。
这仅受“无法自动切换到调度程序”的缺点限制。

They [user-level threads] allow each process to have its own customized scheduling algorithm. For some applications, for example, those with a garbage-collector thread, not having to worry about a thread being stopped at an inconvenient moment is a plus. They also scale better, since kernel threads invariably require some table space and stack space in the kernel, which can be a problem if there are a very large number of threads.

缺点

不与系统调用协调

用户级调度算法不知道是否某个线程调用了阻塞 read系统调用。 OTOH，一个内核级的调度算法会知道，因为它可以通过系统调用得到通知；两者都属于内核代码库。

Suppose that a thread reads from the keyboard before any keys have been hit. Letting the thread actually make the system call is unacceptable, since this will stop all the threads. One of the main goals of having threads in the first place was to allow each one to use blocking calls, but to prevent one blocked thread from affecting the others. With blocking system calls, it is hard to see how this goal can be achieved readily.

他继续说系统调用可以是非阻塞的，但这会非常不方便，并且与现有操作系统的兼容性会受到严重损害。
Tanenbaum 先生还说，系统调用的库包装器(例如在 glibc 中找到的)可以被修改以使用 select 预测系统校准何时阻塞。但他说这很不雅。

在此基础上，他说线程确实经常阻塞。通常阻塞需要许多系统调用。许多系统调用是 坏 .如果没有阻塞，线程就会变得不那么有用:

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.

如果不知道线程，则页面错误会阻塞每个进程

操作系统没有线程的概念。因此，如果发生缺页，整个进程都会被阻塞，有效地阻塞了所有用户级线程。

Somewhat analogous to the problem of blocking system calls is the problem of page faults. [...] If the program calls or jumps to an instruction that is not in memory, a page fault occurs and the operating system will go and get the missing instruction (and its neighbors) from disk. [...] The process is blocked while the necessary instruction is being located and read in. If a thread causes a page fault, the kernel, unaware of even the existence of threads, naturally blocks the entire process until the disk I/O is complete, even though other threads might be runnable.

我认为这可以推广到所有中断。

没有自动切换到调度程序

由于没有每个进程的时钟中断，因此线程永远获取 CPU，除非发生某些依赖于操作系统的机制(例如上下文切换)或它自愿释放 CPU。
这会阻止通常的调度算法工作，包括 Round-Robin algorithm .

[...] if a thread starts running, no other thread in that process will ever run unless the first thread voluntarily gives up the CPU. Within a single process, there are no clock interrupts, making it impossible to schedule processes round-robin fashion (taking turns). Unless a thread enters the run-time system of its own free will, the scheduler will never get a chance.

他说可能的解决方案是

[...] to have the run-time system request a clock signal (interrupt) once a second to give it control, but this, too, is crude and messy to program.

我什至会进一步说，这样的“请求”将需要发生一些系统调用，其缺点已经在“不与系统调用协调”中解释过。如果没有系统调用，那么程序将需要自由访问计时器，这是一个安全漏洞，在现代操作系统中是 Not Acceptable 。