windows中进程的最短保证时间是多少？答案

【问题标题】：What is the minimum guaranteed time for a process in windows?windows中进程的最短保证时间是多少？
【发布时间】：2010-08-24 15:57:59
【问题描述】：

我有一个进程为硬件（数据传输设备）提供特定缓冲区大小。我可以从 windows 调度程序窗口中合理地期望什么，以确保我不会出现缓冲区下溢？

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

如果我以 16k 字节的批次填充它，即每 20 毫秒一个批次。但是，我填充它的下限是多少。如果说，我在填充循环中调用 sleep(0) 我合理的最坏情况调度间隔是多少？

操作系统 = Windows XP SP3 双核 2.2Ghz

请注意，我正在调用 API 来检查缓冲区填充级别，并调用驱动程序 API 以将数据传递给它。我假设这些是除了 sleep(0) 之外 Windows 可以使用的调度点。

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

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

【问题讨论】：

【解决方案1】：

没有保证最坏的情况。 CPU 丢失数百毫秒是很有可能的。无论内核线程正在做什么，您都受制于它们，它们总是以比您所能获得的更高的优先级运行。遇到行为不端的 NIC、USB 或音频驱动程序是您经常遇到的问题。除非你能控制硬件。

如果您可以在偶尔的欠载中幸存下来，请确保您用于获取设备数据的 I/O 请求是可等待事件。 Windows 喜欢调度阻塞在所有其他请求之前完成的 I/O 请求的线程。使用 Sleep() 轮询不是一个好策略。它会不必要地消耗 CPU 周期，并且调度程序根本不会支持线程。

如果您无法在欠载中幸存下来，那么您需要考虑使用设备驱动程序。

【讨论】：

我猜你的意思是中断级和DPC级线程；内核中还有其他优先级较低的线程。
睡眠可能还不错：在最坏的情况下它可能会浪费 CPU，这在专用机器上也不错（占用 CPU 可能是他想要做的）。睡眠的原因可能是他试图让传输缓冲区尽可能满。
是的，一个设备驱动程序。例如，一个标准的串行端口有一个 1 字节或 16 字节的硬件发送缓冲区；串行端口驱动程序接受来自应用程序的多个无限长度缓冲区：所以一个好的应用程序策略是在 2 个大缓冲区上执行 WriteFile，并在驱动程序使用/耗尽/返回其中一个时使用 I/O 请求被唤醒：然后应用程序可以发送下一个（第三个）缓冲区，而设备驱动程序仍然有一个（第二个）缓冲区。
sleep() 最终会调用 yield()，其他进程和线程可以在“睡眠”时运行。不知道占用的东西。 :-)
是否存在基于事件的方案不起作用的原因？当缓冲区已满或快满时，触发事件？

【解决方案2】：

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

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

我还需要考虑什么

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

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

【讨论】：