我有一个在 Windows 7 上运行的数据采集应用程序，使用 C++ 中的 VC2010。一个线程是一个心跳，它每 0.2 秒发送一次更改以保持某些硬件的活动，该硬件的超时时间约为 0.9 秒。通常，心跳调用需要 10-20 毫秒，线程其余时间都在休眠。
然而，偶尔会有 1-2 秒的延迟，并且硬件会立即关闭。心跳线程在 THREAD_PRIORITY_TIME_CRITICAL 运行，对于正常的优先级进程，它是 15。我的其他线程以正常优先级运行，尽管我使用 DLL 来控制其他一些硬件，并且使用 Process Explorer 注意到它启动了几个在 15 级运行的线程。
我无法找到减速的原因，但我的应用程序中的其他问题在发生这种情况时会看到同样的延迟。我对心跳代码做了一些优化，虽然很简单，但偶尔还是会出现故障。现在我想知道是否可以在不为整个进程指定 REALTIME_PRIORITY_CLASS 的情况下将此线程的优先级提高到 15 以上。如果没有，我应该注意使用 REALTIME_PRIORITY_CLASS 有什么缺点吗？（除了这个心跳线程，应用程序的其余部分没有实时计时需求。）
（或者是否有人对如何追踪这些减速有任何想法......不确定源是否可能在我的应用程序中或系统上的其他地方）。
更新：所以我实际上并没有尝试将 31 传递给我的 AfxBeginThread 调用，结果它忽略了该值并将线程设置为正常优先级，而不是我使用 THREAD_PRIORITY_TIME_CRITICAL 获得的 15。
更新：原来运行磁盘碎片整理程序是导致大量线程延迟的好方法。即使在 REALTIME_PRIORITY_CLASS 上运行进程并且在 THREAD_PRIORITY_TIME_CRITICAL（级别 31）上运行心跳线程似乎也无济于事。接下来要尝试的是调用 AvSetMmThreadCharacteristics("Pro Audio")
更新：将心跳线程调度为“Pro Audio”确实可以将线程的优先级提高到 15 以上（Base=1，Dynamic=24），但在碎片整理运行时似乎没有任何真正的区别。我已经能够将许多减速与磁盘碎片整理程序相关联，因此关闭了每周扫描。仍然无法解释一些延迟，所以我们将增加到 5-10 秒的看门狗超时。