【发布时间】：2017-08-28 05:57:55
【问题描述】：
在控制台窗口中运行的应用程序是否被 Windows 调度程序视为“不那么重要”，即如果最小化，Windows 是否允许它“休眠”更长时间？我以为我读过一些关于 Windows 会降低其优先级的文章，如果它被最小化，但也许我只是混淆了一些东西。
问题是，我有一个 C 控制台应用程序（用 VS2015 编写，但在 Windows Server 2008 R2 上运行，所以不支持 GetSystemTimePrecise，不幸的是），它进行一些套接字通信，但有时接收线程 (IOCP)暂停，数据包合并在一起。
所以，在我的主要功能中，我写了这样的东西：
timeBeginPeriod(1);
while (true)
{
QueryPerformanceCounter(&start);
Sleep(1);
QueryPerformanceCounter(&stop);
LogTimeElapsed(start, stop);
}
我显然没想到Sleep(1) 会达到毫秒级的精度，但我很惊讶地发现了大约 50 毫秒的大量延迟，有几次最大达到超过 120 毫秒。
当然，在此期间，还有其他活动进程消耗 CPU（执行一些数据库导出和类似操作，总 CPU 将达到约 50%），但由于这是一个四核 CPU，我认为线程调度程序会仍然防止发生如此长时间的延误。
这是作为普通控制台应用程序运行的产物，还是我应该预期任何 Windows 桌面/服务应用程序都会出现类似的延迟？
【问题讨论】：
-
答案取决于服务器上运行的内容，但一般来说，您不能期望睡眠功能具有很高的准确性，应该围绕此设计代码。如果您需要更高的准确性，也许您需要计时器之类的东西。
-
这有点 XY 的味道。使用 TCP，“数据包合并在一起”是经过设计的。使用 UDP，数据包通过错误合并在一起。尽管如此，考虑到你的小循环，我很惊讶你曾经在一个轻负载的四核盒子上得到这么多的延迟。 Sleep(1) 也可以是 Sleep(0)，本质上是一个重新调度内核调用。
-
嗯...，接收线程 (IOCP) 暂停并且 数据包合并在一起 究竟是什么意思？说到重新排列 TCP 数据包？
-
@this.lau_：代码的重点是检查延迟的来源，因为我没有看到我在应用程序的其他部分检测到的一些延迟的任何原因.
-
@ThingyWotsit：我明白你在说什么，但问题是：数据包每 20 毫秒由同一交换机上的设备发送一次，我可以在 Wireshark 中看到它们在此运行同一台机器，即对于每个 TCP 数据包，接收数据包的时间与传感器报告的时间相匹配，有（比如说）5 毫秒延迟（服务器和传感器都是时间同步的）。但是我看到我的测试控制台应用程序得到了这些延迟，之后下一个 recv 调用得到合并的数据包。
标签： c windows multithreading sleep thread-priority