然而偶尔会出现1-2秒的延迟，硬件将瞬间关闭。心跳线程以THREAD_PRIORITY_TIME_CRITICAL（优先级15）运行，这是正常优先级进程的标准。我的其他线程以普通优先级运行，尽管我使用DLL来控制其他硬件，并且发现Process Explorer启动了几个以等级15运行的线程。
我无法找到减速的来源，但当这种情况发生时，我的应用程序中的其他线程也会遇到类似的延迟。即使这个心跳代码非常简单，我已经进行了几次优化，但偶尔的失败仍在发生。现在我想知道是否可以将此线程的优先级提高到15之外，而不指定整个进程的REALTIME_PRIORITY_CLASS。如果不能，除了这个心跳线程之外，其他部分的应用程序并没有实时时间需求，我应该注意使用REALTIME_PRIORITY_CLASS的任何副作用吗？
（或者有没有人对如何追踪这些减速有任何想法...不确定源头是否可能在我的应用程序中或系统上的其他地方）。
更新：所以我实际上还没有尝试将31传递到我的AfxBeginThread调用中，结果它会忽略该值，并将线程设置为普通优先级，而不是THREAD_PRIORITY_TIME_CRITICAL的15。
更新：事实证明运行磁盘碎片整理器是导致许多线程延迟的好方法。即使以REALTIME_PRIORITY_CLASS运行进程并将心跳线程设置为THREAD_PRIORITY_TIME_CRITICAL（级别31），似乎也无济于事。下一步要尝试的是调用AvSetMmThreadCharacteristics（“Pro Audio”）。
更新：将心跳线程调度为“Pro Audio”可以增加线程的优先级超过15（基础=1，动态=24），但在运行碎片整理器时似乎没有什么实质性的区别。我已经能够将许多延迟与磁盘碎片整理器相关联，因此关闭了每周扫描。仍然无法解释一些延迟，因此我们将增加到5-10秒的看门狗超时时间。