Windows 上的上下文切换之间的时间范围是多长时间？答案

【问题标题】：How long is the time frame between context switches on Windows?Windows 上的上下文切换之间的时间范围是多长时间？
【发布时间】：2010-05-20 15:21:29
【问题描述】：

通过 C# 2.0 读取 CLR（我目前没有 3.0）

还是这样吗：

如果计算机中只有一个 CPU，那么任何时候都只能运行一个线程。 Windows 必须跟踪线程对象，并且每隔一段时间，Windows 必须决定接下来调度哪个线程以进入 CPU。这是必须每 20 毫秒左右执行一次的附加代码。当 Windows 使 CPU 停止执行一个线程的代码并开始执行另一个线程的代码时，我们称之为上下文切换。上下文切换相当昂贵，因为操作系统必须：

所以通过 C# 2.0 的 CLR 可以说我们使用的是 Pentium 4 2.4ghz 1 core non-HT, XP。每 20 毫秒？ CLR 线程或 Java 线程映射到 OS 线程时，每秒最多只有 50 个线程可能有机会运行？

我在 SO 上读到，上下文切换在微秒内非常快，但大概（大小风格猜测）会说一个适度的 5 年历史服务器 Windows 2003 Pentium Xeon 单核给操作系统提供了机会的频率 到上下文切换？ 20ms 在正确的区域？

我不需要确切的数字我只是想确定它在正确的区域，对我来说似乎相当长。

【问题讨论】：

标签： multithreading context-switching

【解决方案1】：

所谓的 Quantum 取决于一些因素，包括操作系统在运行过程中所做的性能调整；例如，前台进程被赋予更高的优先级，并且可以被赋予[比默认值长 3 倍的时间量。服务器和客户端 SKU 之间也存在差异，通常客户端的默认时间间隔为 30 毫秒，而服务器为 180 毫秒。

因此，需要尽可能多的 CPU 的前台进程可能会在上下文切换之前获得 90 毫秒的时间片......然后操作系统可能会决定它不需要切换并让 Quantum 继续。

【讨论】：

【解决方案2】：

您的“一次 50 个线程”的数学运算是错误的。您假设每个线程都处于 100% CPU 状态。大多数线程实际上在等待 IO 或其他事件时处于休眠状态。即便如此，大多数线程在进入 IO 模式或以其他方式放弃其切片之前并没有使用它们的整个 20 毫秒。

试试这个。编写一个无限循环的应用程序（吃掉它的整个 CPU 窗口）。运行它的 50 个实例。看看 Windows 的反应。

【讨论】：

43 个线程在 100% 时会看到一些 CPU。当他们在几毫秒（睡眠）但 1000+ 后放弃共享时，无法获得足够的线程来获得结果
CPU 100%。没有看到调试器 125 cpu 绑定线程，这表明 20 毫秒在 Windows7 中已过时。实际的 exe 显然在六个 .net 内部线程之间切换了数千次pan>

【解决方案3】：

我刚刚做了一个测试，我在一秒钟内看到了 43 个线程（在预热之后），这使得 Richter 语句非常准确（有开销）我说。四核/Win7/64位。是的，这些都是 100% cpu 线程，所以很明显它们在 20 毫秒之前没有被收回。有趣

【讨论】：