task - 线程池和上下文切换(任务)？

Question

这是一个相当普遍的计算机科学问题，并不特定于任何操作系统或框架。

因此，我对与在线程池上切换任务相关的开销感到有些困惑。在许多情况下，给每个作业分配自己的特定线程是没有意义的(我们不想创建太多硬件线程)，因此我们将这些作业放入可以安排在线程上运行的任务中。我们设置了一个线程池，然后动态分配任务以在从线程池中取出的线程上运行。

我对与在特定线程(在线程池中)上切换任务相关的开销有点困惑(找不到深入的答案)。 DrDobbs 的一篇文章(来源如下)表示确实如此，但我需要更深入地回答实际发生的事情(可引用的来源会很棒:))。

By definition, SomeWork must be queued up in the pool and then run on a different thread than the original thread. This means we necessarily incur queuing overhead plus a context switch just to move the work to the pool. If we need to communicate an answer back to the original thread, such as through a message or Future or similar, we will incur another context switch for that.

来源: http://www.drdobbs.com/parallel/use-thread-pools-correctly-keep-tasks-sh/216500409?pgno=1

线程的哪些组件实际上在切换？线程本身实际上并没有切换，只是特定于线程的数据。与此相关的开销是多少(更多、更少或相同)？

Answer 1

让我们在这里澄清前 5 个关键概念，然后讨论它们在线程池上下文中的相关性:

线:
在简短的简历中，它可以被描述为一个程序执行上下文，由正在运行的代码、cpu 注册表中的数据和堆栈给出。当一个线程被创建时，它被分配了应该在该线程上下文中执行的代码。在每个 cpu 周期中，线程都有一条指令要执行，并且 cpu 注册表和堆栈中的数据处于给定状态。

任务:
代表一个工作单元。它是分配给要执行的线程的代码。

上下文切换(来自维基百科):
是存储和恢复线程状态(上下文)以便稍后可以从同一点恢复执行的过程。这使多个进程能够共享单个 CPU，并且是多任务操作系统的基本功能。如上所述，构成上下文的是正在执行的代码、cpu 注册表和堆栈。

上下文切换的是线程。任务仅代表可以分配给要执行的线程的工作和平。在给定时刻，线程可以执行任务。

线程池(来自维基百科):
在计算机编程中，线程池是创建多个线程以执行多个任务的地方，这些任务通常组织在一个队列中。

线程池队列:
任务放置在池中由线程执行的位置。此数据结构是共享内存和平，其中线程可能会竞争排队/出队，在高负载情况下可能会导致争用。

说明一个线程池使用场景:

在您的程序中(最终在主线程中运行)，您创建一个任务并安排它在线程池中执行。

任务在线程池队列中排队。

当池中的线程执行时，它会从池中取出任务并开始执行它。

如果没有空闲的 CPU 来执行池中的线程，操作系统在某个时刻(取决于线程调度程序策略和线程优先级)将停止一个线程的执行，上下文切换到另一个线程。

操作系统可以随时停止一个线程的执行，上下文切换到另一个线程，返回到另一个线程在它停止的地方继续。

当竞争 CPU 的事件线程数量增加时，上下文切换的开销会增加。因此，理想情况下，线程池尝试使用最少的必要线程来占用机器中所有可用的 CPU。

如果您的任务没有在某处阻塞的代码，上下文切换将被最小化，因为它使用的线程不超过机器上可用的 CPU。

当然如果你只有一个核心，你的主线程和线程池会争夺同一个cpu。