调度和线程量子答案

【问题标题】：Scheduling and thread quantum调度和线程量子
【发布时间】：2018-06-05 14:13:06
【问题描述】：

我想知道线程过多是否会影响分配给特定线程的时间量。

例如，如果我的进程有 100 个线程，那么下一个/调度线程的量子/突发是否比拥有 1000 个线程的量子/突发少，因为调度需要更多时间？

IMO，由于调度运行它自己的进程，它有自己的线程来执行调度，因此它不应该影响其他线程的量子（但应该为下一个/调度线程的执行引入一些延迟）。

还有什么想法吗？

【问题讨论】：

请解释一下“一对多环境”是什么意思。除了内核管理的线程之外，没有任何主流语言/库使用任何东西，所以这将是一对一的，原因很简单，任何其他机制都会对代码结构施加限制（例如，'你不能制作任何直接操作系统可能会阻塞的呼叫），大多数用户不希望或无法应对。你的问题不清楚。
我想说“一对一”，但我打错了。现在，我删除了那部分。

标签： multithreading operating-system cpu scheduling

【解决方案1】：

除非您的操作系统从头开始设计为hard-real-time OS（例如Xenomai 或VxWorks），否则您会发现操作系统的调度程序提供的关于您的线程何时获得的保证非常非常少跑步，或者当他们跑步时他们将继续跑步多长时间。

鉴于上述情况，同一台计算机上存在其他线程（无论它们是您自己的进程中的线程还是其他进程中的线程）很可能会影响您自己的线程接收的 CPU 时间量。例如，如果其他线程以比您的线程更高的优先级运行，并且存在 CPU 内核争用（即在特定时间想要运行的线程多于运行它们的 CPU 内核），那么调度程序将在其时间片到期之前将您正在运行的线程之一从其当前 CPU 内核中踢出，以便现在准备好运行的高优先级线程可以立即开始执行。

一般来说，这类问题的答案是“有龙”的种类——也就是说，如果您正确编写了多线程程序，那么您不必知道（或关心）您的线程接收的量子大小是多少，因为无论调度程序如何将时间片分配给线程，您的代码都应该能够正确运行。

（当您absolutely need real-time behavior 时例外；在这种情况下，您可能希望在可以为您提供所需保证的实时操作系统上运行）

至于调度器需要多少时间来确定哪个线程开始运行，线程越多确实会增加调度器的开销，但是在大多数操作系统上增加的幅度很小——调度算法是O(log N)甚至O(1) 与线程数有关。当然，如果你无限期地继续添加更多线程，你仍然可以让计算机“碰壁”，但你最终达到的限制更有可能与 RAM 耗尽有关，而不是与调度算法的性能有关。

【讨论】：

感谢详细的解释！但是如果调度程序启动它自己的线程（或进程），或者它“窃取”当前正在运行的内核线程的一些时间，我仍然不太明白。
我从未听说过有自己的线程或进程的调度程序。而是一个中断发出，正在运行的用户线程被暂时挂起，而中断例程运行一个调度程序函数，该函数决定下一个允许哪个线程运行。

【解决方案2】：

使用令人困惑的“一对多”术语，您真正处理的是模拟线程。这不是操作系统实现，而是库实现。库将不了解量子，操作系统将不了解线程。因此，正如您所建议的那样，线程对量子和进程调度的影响为零。

【讨论】：

很抱歉给您带来了困惑。我之所以这么说，是因为在某些语言上，您不能直接创建内核线程，这可能最终会影响调度程序的压力，对吧？好吧，您总是可以创建一个流程（或轻量级流程）以在这些语言上实现您想要的（压力明智），但这不是我的意思。无论哪种方式，您的系统拥有的线程越多，调度程序花费更多的时间来确定应该为哪个进程/线程提供一个槽/突发来运行。我的问题是调度“延迟”会以任何方式影响这个突发时间吗？