getrusage()減算によってタスクの時間を取得するために 2 回呼び出すプログラムで、タスクの時間が非負でなければならないというアサーションが失敗するのを見たことがあります。もちろん、これを簡単に再現することはできませんが、より簡単に再現できる特殊なプログラムを作成することはできます。
私は実行に伴って増加する保証を見つけようとしましたgetrusage()が、私のシステム (x86-64 上の Linux) のマニュアルページも、このシステムに依存しない説明も明示的に述べていません。
この動作は、複数のコアがあり、NTP が実行されている物理コンピューターで観察されました。
使用している OS に対するバグを報告する必要がありますか? getrusage()時間の経過とともに増加すると予想される場合、私はあまりにも多くを求めていますか?
多くのシステムでは rusage (つまり と を意味ru_utimeしていると思いますru_stime) は正確に計算されず、クロック ティックごとに 1 回サンプリングされるだけで、通常は 100Hz ほど遅く、時にはさらに遅くなります。
その主な理由は、多くのマシンには読み取りに非常にコストがかかるクロックがあり、この計算を実行したくないためです (システム コールごとにクロックを 2 回読み取る必要があります)。多数のシステム コールを実行するプログラムでは、他の処理よりもクロックの読み取りに多くの時間を費やすことになりがちです。
ただし、カウンターは決して後退してはなりません。何年も前に、プロセスの合計実行時間がコンテキスト スイッチで追跡されているのを見てきました (これは比較的安価で、getrusge は stime のサンプルを使用して合計実行時間から差し引くことで utime を計算できました)。その場合に使用された時計は、単調な時計ではなく壁時計であり、マシンの時間を変更すると、プロセスの実行時間が戻る可能性がありました。しかし、それはもちろんバグでした。