我有一個運行在Windows 7上的數據採集應用程序，使用C++中的VC2010。一個線程是一個心跳，它每隔0.2秒發出一次更改以保持某些硬件的超時時間約爲.9秒。通常情況下，心跳呼叫需要10-20毫秒，並且線程花費其餘時間休眠。對於普通優先級進程，我可以將單個線程的優先級設置爲15以上嗎？
但是偶爾會有1-2秒的延遲，硬件會暫時關閉。心跳線程在THREAD_PRIORITY_TIME_CRITICAL上運行，對於正常優先級進程，該值爲15。我的其他線程以正常優先級運行，儘管我使用DLL來控制一些其他硬件，並且已經注意到使用Process Explorer啓動了多個運行在級別15的線程。
我無法追查慢速但在我的應用程序中的其他角色在發生這種情況時會看到相同類型的延遲。我已經對心跳代碼進行了幾次優化，儘管它很簡單，但偶爾的故障仍在發生。現在我想知道如果沒有爲整個過程指定REALTIME_PRIORITY_CLASS，我是否可以將該線程的優先級提高到15以上。如果不是，我是否應該注意使用REALTIME_PRIORITY_CLASS有什麼缺點？ （除了這個心跳線程，應用程序的其餘部分沒有實時定時需求。）
（或沒有人有任何關於如何追蹤這些減速的想法...不知道源是否可以在我的應用程序或系統中的其他地方）。
更新：所以我還沒有真正嘗試通過31進我AfxBeginThread電話，原來它忽略了價值，並設置線程正常優先級，而不是15，我與THREAD_PRIORITY_TIME_CRITICAL得到。
更新：發現運行磁盤碎片整理程序是導致大量線程延遲的好方法。即使在REALTIME_PRIORITY_CLASS和THREAD_PRIORITY_TIME_CRITICAL（31級）的心跳線程上運行該進程似乎也沒有幫助。接下來的事情，試圖呼籲AvSetMmThreadCharacteristics（「專業音響」）
更新：調度心跳線爲「專業音響」做工作，以增加超過15線程的優先級（基地= 1，動態= 24），但它不似乎在碎片整理運行時會產生真正的差異。我已經能夠將磁盤碎片整理程序的許多減速與關閉每週掃描相關聯。仍然無法解釋一些延遲，所以我們將增加到5-10秒的看門狗超時。
當人們在有關Windows編程問題，使用像「心跳」和「關閉出於安全原因」的話它讓我害怕。 :)這當然不是一個RTOS：http://en.wikipedia.org/wiki/Real-time_operating_system – HostileFork
我認爲你的看門狗是嚴格的。在RTOS上500ms很多，但在Windows上15秒以下是有風險的。如果你對你的看門狗有控制權，那麼我建議讓超時時間更長，或者只有當它失去了一定數量的觸發器時才讓它關閉。 – Fozi
問題：什麼時候您的硬件將關閉？ – Fozi