私はC++でVC2010を使用してWindows 7上で動作するデータ収集アプリケーションを用意しています。 1つのスレッドは、0.2秒ごとに変更を送信して約0.9秒のタイムアウトを持つハードウェアを保持するハートビートです。通常、ハートビートコールには10〜20msかかり、スレッドは残りの時間をスリーピングに費やします。通常の優先順位プロセスで、単一スレッドの優先度を15以上に設定できますか？
ただし、1〜2秒の遅延があり、ハードウェアが一時的にシャットダウンします。ハートビートスレッドは、THREAD_PRIORITY_TIME_CRITICAL（通常の優先プロセスの場合は15）で実行されています。他のハードウェアを制御するためにDLLを使用していて、プロセスエクスプローラでレベル15で実行されているいくつかのスレッドを開始したことに気づいたにもかかわらず、他のスレッドは通常の優先順位で実行されています。
遅い私のアプリケーションの他のtheadsは、これが起こると同じ種類の遅延を見ている。私はかなりシンプルですが、ハートビートコードに対していくつかの最適化を行っていますが、時折起こっている不具合はまだ起きています。今私は、プロセス全体に対してREALTIME_PRIORITY_CLASSを指定せずに、このスレッドの優先度を15を超えて上げることができるのだろうかと思います。そうでない場合は、REALTIME_PRIORITY_CLASSを使用することに注意しなければならない短所はありますか？ （このハートビートスレッド以外は、アプリケーションの残りの部分でリアルタイムのタイミングが必要ない）
（または、これらの減速を追跡する方法については誰にも分かりません。私のアプリやシステムの他のどこかに）。
更新：私は実際にAfxBeginThread呼び出しに31を渡すことはしませんでした。その値を無視し、THREAD_PRIORITY_TIME_CRITICALで取得する15の代わりに通常の優先順位にスレッドを設定します。
更新：ディスクデフラグツールの実行は、多くのスレッド遅延を引き起こす良い方法です。 REALTIME_PRIORITY_CLASSでプロセスを実行しても、THREAD_PRIORITY_TIME_CRITICAL（レベル31）でハートビートスレッドを実行しても役立たないようです。 （Pro Audio）
更新：ハートビートスレッドを「Pro Audio」としてスケジューリングすると、スレッドの優先度が15（Base = 1、Dynamic = 24）を超えるように動作しますが、そうではありません。デフラグが実行されているときには本当の違いがあるようです。私は減速の多くをディスクデフラグツールと関連付けることができ、毎週スキャンを止めました。まだいくつかの遅延を説明することはできませんので、5〜10秒のウォッチドッグタイムアウトまで増加させていきます。
は、それは私をおびえさせる：
は、そうでなければ、あなたがカーネルの部品を不正な動作しているかどうかを伝えることができるソフトウェアがあります。 :)それは確かにRTOSではありません：http://en.wikipedia.org/wiki/Real-time_operating_system – HostileFork
私はあなたの監視が厳格であると思います。 RTOSでは500msは十分ですが、Windowsでは15秒以下のものは危険です。ウォッチドッグを制御できる場合は、タイムアウトを長くするか、トリガーが一定数失った場合にのみシャットダウンするようにしてください。 – Fozi
質問：ハードウェアがシャットダウンするまでの時間はどのくらいですか？ – Fozi