当CPU内核可用时，什么会使Windows调度程序忽略高优先级线程？

Question

我有一个多线程应用程序，其中一个线程具有时间紧迫的工作。启动时，此时间紧迫线程将设置为“时间紧迫”优先级。此外，应用程序中的其他线程都设置了处理器亲和力掩码，因此，这个时间紧迫的线程始终可以完全访问8个CPU内核（两个Xeon中共有12个CPU内核）。服务器上没有其他应用程序在运行（Windows自己运行的服务除外）。

尽管如此，即使采取了所有这些预防措施，我仍然记录了一些事件，这些事件在这个时间紧迫的线程中一次没有运行80-100ms。我的日志记录表明，有时它会中止任务，并在经过80-100毫秒的时间后再次恢复。

我的问题是：是什么原因导致这些80-100ms线程中断，和/或我如何找出导致这些中断的原因？

一些其他可能相关的信息：

• 停电与other应用程序线程上的大量活动密切相关，但是我正在资源监视器中监视CPU使用情况图表，并且可以看到专用于时间紧迫任务的CPU远远少于100％（但是具有完全访问权限的4个用户在此期间通常为100％）
• 在这些高峰性能时段中，网络活动也很活跃，在这些时段中往往会发生断电。
• 时间紧迫的任务通过PCIe通信与硬件连接，但是与该设备通话时不一定会发生“中断”事件。
• [当一切正常工作时，时间紧迫的线程仅花费大约1-2ms来完成工作，然后在繁忙的循环中等待大约30ms。
• 时间紧迫的任务确实与其他一些线程共享资源，但是通过自旋锁进行了保护，并且日志记录表明在等待锁定时未发生中断。另外，我可以看到这些其他线程在按住自旋锁的过程中并没有停留超过几微秒的时间。
• 通过任务管理器将应用程序优先级更改为“ HIGH”不会提高性能
• 我有运行Win7和Win10的测试服务器，并且都显示了问题。

Answer 1

过去几天我进行了许多测试，并且能够收集一些有趣的数据，下面将对其进行总结。

1. 几乎在CPU处于空闲状态时几乎不会发生该问题
2. 我很容易通过从另一个进程中释放CPU来引发故障，而该进程只是简单地使用许多线程来消耗它
3. 我以为我可以通过使用进程亲和力掩码限制大多数线程并将时间紧迫的线程留在自己的专用CPU上来减少问题。但是，事实证明这不是一个完整的解决方案，因为存在一些共享锁（传递信息和日志记录设施）会引起争用问题。短暂持有关键锁的高争用但低优先级线程将在持有该锁时进入睡眠状态，而让我的高优先级线程（在闲置的cpus上请注意）。
4. 到目前为止，我进行的最有趣的测试是采用故障率较高的特定Windows 7测试系统，并且我在相同的硬件上安装了全新的Windows 10副本并运行了相同的软件。在相同的精确操作条件下，这大大降低了故障率。

最终，我认为问题归结于Windows无法很好地处理1）线程优先级，尤其是2）优先级反转问题。令人惊讶的是，Windows 10似乎比Windows 7更好地处理了这些问题。

Microsoft关于操作系统如何处理优先级倒置的简短article，但是当CPU负载了多个线程时，这种策略似乎不足以防止关键线程上的长时间延迟，特别是在Windows 7上，这似乎是不足的。