Windows中进程的最短保证时间是多少？

Question

我有一个进程，它为一块具有特定缓冲区大小的硬件（数据传输设备）提供信息。我可以合理地期望从windows调度程序窗口中获得缓冲区下溢吗？

我的缓冲区大小为32K，每秒消耗约800k字节。

如果我填写16k字节批次，即每20ms一批。但是，填充它的下限是多少。如果说，我在填充循环中调用sleep（0），这是我合理的最坏情况调度间隔吗？

OS = Windows XP SP3 双核2.2Ghz

注意，我正在进行API调用以检查缓冲区填充级别以及对驱动程序API的调用以将数据传递给它。我假设这些是除睡眠（0）之外Windows可以使用的调度点。

我想（作为一个过程）玩得很好，仍然符合我的实时截止日期。机器专用于此任务，但需要通过网络接收数据并将其发送到IO设备。

我对调度程序性能有什么期望？ 我还需要考虑什么呢。

Answer 1

  

Windows中进程的最短保证时间是多少？

无法保证：Windows不是实时操作系统。

  

我还需要考虑什么

• 机器上还有其他什么（高优先级可能会抢占你）
• 你有多少内存（当RAM供不应时，系统性能会发生很大变化）
• 您是否是I / O（因为您可能会在等待磁盘或网络访问时失速）

  

我想（作为一个过程）玩得很好，仍然符合我的实时截止日期。机器专用于此任务，但需要通过网络接收数据并将其发送到IO设备。

考虑以“实时优先级”设置进程和/或线程的优先级。

Answer 2

没有保证最坏情况。丢失CPU几百毫秒是完全可能的。你受到内核线程正在做的任何事情的影响，它们总是以比你所能得到的更高的优先级运行。遇到行为不端的NIC，USB或音频驱动程序是一个你经常会遇到的问题。除非你可以控制硬件。

如果偶尔运行不足，请确保用于获取设备数据的I / O请求是一个可等待的事件。 Windows喜欢调度在I / O请求上阻塞的线程，该I / O请求在所有其他I / O请求之前完成。使用Sleep（）进行轮询并不是一个好策略。它不必要地烧掉CPU周期，调度程序根本不会支持线程。

如果你无法在欠载中存活，那么你需要考虑设备驱动程序。