Thread.Sleep现在使用的是高分辨率定时器还是Windows10改变了默认的系统时钟频率？

Question

Thread.Sleep通常与系统时钟相关联，系统时钟的时钟间隔大约为16毫秒，因此任何低于16毫秒的时间都会产生16毫秒的睡眠。这种行为似乎在某种程度上发生了变化。

发生了什么变化？Thread.Sleep是否不再与系统时钟相关联，而是与高分辨率计时器相关联？还是在Windows 10中增加了默认系统时钟频率？

编辑:似乎人们有兴趣知道我为什么使用Thread.Sleep，这实际上超出了问题的范围，问题是为什么行为发生了变化。但不管怎样，我注意到了我的开源项目freepie https://andersmalmgren.github.io/FreePIE/中的变化

它是一个输入/输出仿真器，由最终用户使用Iron python控制。它在后台运行。它没有自然的中断。所以我需要编组脚本线程，这样它就不会耗尽整个内核。

Answer 1

感谢我第一次错过的Hans Passant评论，我找到了问题所在。事实证明，Nvidias driver suit才是问题的制造者。

平台计时器分辨率:未完成的计时器请求程序或服务请求的计时器分辨率小于平台的最大计时器分辨率。请求期间10000请求进程ID 13396请求进程路径\设备\硬盘卷2\程序文件\NVIDIA Corporation\NVIDIA GeForce Experience\NVIDIA Share.exe

这在很多层面上都是愚蠢的。从长远来看，这甚至对环境不利，因为任何安装了nvidia的计算机都会消耗更多的电量。

编辑: Hans评论，相关部分：

有太多的程序想要搞乱它，排在首位的是一家销售移动操作系统的公司的免费产品。从提升的命令提示符运行powercfg /energy，以在生成的报告中找到作弊工具“平台计时器解决方案”。

Answer 2

新的硬件确实有一个更精确的计时器。但是Thread.Sleep的目的不是精确地说，它不应该被用作计时器。

一切都在documentation中

如果dwMilliseconds小于系统时钟的分辨率，则线程休眠的时间可能少于指定的时间长度。如果dwMilliseconds大于一个刻度但小于两个刻度，等待时间可以介于一个刻度到两个刻度之间，依此类推。

同样非常重要的是，在经过一段时间后，您的线程不会自动运行。取而代之的是，线程被标记为准备运行。这意味着只有当没有更高优先级的线程也准备好运行时，它才会获得时间，而不是在当前运行的线程耗尽它们的量程或进入等待状态之前。