Windows 上上下文切换之间的时间范围是多长？
通过C# 2.0读取CLR（我现在没有3.0）
还是这样吗：
如果一台计算机只有一个CPU，那么任何时候只能运行一个线程。 Windows 必须跟踪线程对象，并且每隔一段时间，Windows 就必须决定接下来调度哪个线程来访问 CPU。这是额外的代码，必须每 20 毫秒左右执行一次。当 Windows 使 CPU 停止执行一个线程的代码并开始执行另一个线程的代码时，我们称之为上下文切换。上下文切换相当昂贵，因为操作系统必须：
所以大约通过 C# 2.0 的 CLR 可以说我们使用的是 Pentium 4 2.4ghz 1 核心非 HT、XP。每 20 毫秒一次？如果 CLR 线程或 Java 线程映射到操作系统线程，每秒最多只能有 50 个线程可能有机会运行？
我读到，上下文切换速度非常快，以微秒为单位，但粗略地（大小风格猜测）会说一台普通的 5 年旧服务器 Windows 2003 Pentium Xeon 单核为操作系统提供了机会机会 上下文切换？ 20ms 在正确的区域吗？
我不需要确切的数字，我只是想确保它在正确的区域，对我来说似乎相当长。
Reading CLR via C# 2.0 (I dont have 3.0 with me at the moment)
Is this still the case:
If there is only one CPU in a computer, only one thread can run at any one time. Windows has to keep track of the thread objects, and every so often, Windows has to decide which thread to schedule next to go to the CPU. This is additional code that has to execute once every 20 milliseconds or so. When Windows makes a CPU stop executing one thread's code and start executing another thread's code, we call this a context switch. A context switch is fairly expensive because the operating system has to:
So circa CLR via C# 2.0 lets say we are on Pentium 4 2.4ghz 1 core non-HT, XP. Every 20 milliseconds? Where a CLR thread or Java thread is mapped to an OS thread only a maximum of 50 threads per second may get a chance to to run?
I've read that context switching is very fast in mircoseconds here on SO, but how often roughly (magnitude style guesses) will say a modest 5 year old server Windows 2003 Pentium Xeon single core give the OS the opportunity to context switch? 20ms in the right area?
I dont need exact figures I just want to be sure that's in the right area, seems rather long to me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
所谓的 Quantum 取决于一些因素，包括操作系统在运行过程中所做的性能调整；例如，前台进程被赋予更高的优先级，并且可以被赋予[比默认长3倍的量子。服务器和客户端 SKU 之间也存在差异，通常客户端的默认时间量为 30 毫秒，而服务器的默认时间量为 180 毫秒。
因此，需要尽可能多的 CPU 的前台进程可能会在上下文切换之前获得 90 毫秒的时间量。然后操作系统可能会决定不需要切换并让量程继续进行。
The Quantum as it's called is dependant on a few things, including performance tweaks the operating system makes as it goes along; for instance the foreground process is given a higher priority and can be given [a quantum 3 times longer than default. There is a also a difference between Server and Client SKU typically a client would have a default quantum of 30ms where a server would be 180ms.
So a foreground process that wants as much CPU as it can get may get a quantum of 90ms before a context switch.. and then the OS may decide it doesn't need to switch and let the Quantum continue.
您的“一次 50 个线程”数学是错误的。您假设每个线程都处于 100% CPU 状态。大多数线程实际上处于休眠状态，等待 IO 或其他事件。即使如此，大多数线程在进入 IO 模式或以其他方式放弃其切片之前也不会使用整个 20 毫秒。
试试这个。编写一个具有无限循环的应用程序（占用整个 CPU 窗口）。运行它的 50 个实例。查看 Windows 的反应。
Your "50 threads at a time" math is wrong. You assume that each of those threads is in a 100% CPU state. Most threads are in fact asleep waiting for IO or other events. Even then, most threads don't use their entire 20 ms before going into IO mode or otherwise giving up its slice.
Try this. Write an app with an inifinite loop (eats its entire CPU window). Run 50 instances of it. See how Windows reacts.
我刚刚做了一个测试，我有 43 个线程在一秒钟内看到它的份额（在预热之后），这使得 Richter 声明非常准确（有开销）。四核/Win7/64位。是的，这些是 100% 的 cpu 线程，所以显然它们在 20 毫秒之前没有恢复正常。有趣的
I just did a test I got 43 threads seeing its share in a second (after warming up) which makes Richter statement pretty accurate (with overhead) I say. Quadcore/Win7/64bit. Yes these were 100% cpu threads so obviously they weren't given themselves back before their 20ms. Interesting