线程处于 user-space 调度困境
Thread in user-space schedulling dilemma
最近我开始（再次）阅读 Tanenbaum 的 'Modern Operating Systems 4ed'，我有点卡在讨论进程和线程的第 2 章中。特别是我对 user-space threads 子章节感到困惑，该章节列出了它们的所有优点和缺点。
这是支持用户-space 线程的直接引用：
User-level threads also have other advantages. They 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.
我的理解是，每个使用线程的进程（因此创建 them/destroy）负责实施这些线程的调度，以便它们高效运行。例如，具有预定义的短时间间隔的简单循环。
然而，在子章的后面，我们会引用缺点。来了：
Another problem with user-level thread packages is that 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.
嗯，WTF？因此，在优点方面，拥有进程的线程 OWN 调度程序是一个优势，这里似乎无论是否有定制的调度程序 - 它都不会像预期的那样工作，因为线程是贪婪的。
我的问题是：在使用用户space 线程时，进程的调度程序是否不可能以平等的方式实际调度线程？还是我的英文不够好，没能抓住这里的一个要点。
PS。在查看已发布的问题时，建议我阅读此 - User-level threads for threading。声明 Tanenbaum 的模型适用于旧系统不是正确的吗？这本书于 2014 年发行，所以这可能是一回事。
调度算法是从一组 运行 可用线程中选择下一个应该 运行 的算法。这是您可以在用户空间线程系统中随意设计的部分。
“缺点”部分中的文字谈论的是 当调度算法达到 运行 时，并且说对于用户空间线程，您通常限于只有当当前 运行ning 线程自愿进入调度程序时才会发生。
所以优点是指当调度器运行s时会发生什么，缺点是指当调度器到达运行.
最近我开始（再次）阅读 Tanenbaum 的 'Modern Operating Systems 4ed'，我有点卡在讨论进程和线程的第 2 章中。特别是我对 user-space threads 子章节感到困惑，该章节列出了它们的所有优点和缺点。
这是支持用户-space 线程的直接引用：
User-level threads also have other advantages. They 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.
我的理解是，每个使用线程的进程（因此创建 them/destroy）负责实施这些线程的调度，以便它们高效运行。例如，具有预定义的短时间间隔的简单循环。
然而，在子章的后面，我们会引用缺点。来了：
Another problem with user-level thread packages is that 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.
嗯，WTF？因此，在优点方面，拥有进程的线程 OWN 调度程序是一个优势，这里似乎无论是否有定制的调度程序 - 它都不会像预期的那样工作，因为线程是贪婪的。
我的问题是：在使用用户space 线程时，进程的调度程序是否不可能以平等的方式实际调度线程？还是我的英文不够好，没能抓住这里的一个要点。
PS。在查看已发布的问题时，建议我阅读此 - User-level threads for threading。声明 Tanenbaum 的模型适用于旧系统不是正确的吗？这本书于 2014 年发行，所以这可能是一回事。
调度算法是从一组 运行 可用线程中选择下一个应该 运行 的算法。这是您可以在用户空间线程系统中随意设计的部分。
“缺点”部分中的文字谈论的是 当调度算法达到 运行 时，并且说对于用户空间线程，您通常限于只有当当前 运行ning 线程自愿进入调度程序时才会发生。
所以优点是指当调度器运行s时会发生什么，缺点是指当调度器到达运行.