Windowsスケジューラの動作はWindows10 2004で大幅に変更されましたが、警告やドキュメントの変更はありません。これにより、いくつかのアプリケーションが破損する可能性があります。これが起こったのはこれが初めてではありませんが、この変化はより深刻です。



つまり、あるプロセスからtimeBeginPeriodを呼び出すと、他のプロセスへの影響は以前よりも少なくなりますが、その影響はまだ存在します。



新しい動作は本質的に改善されたものだと思いますが、それは奇妙であり、文書化する価値があります。正直なところ、私はあなたに警告します-私は自分の実験の結果しか持っていないので、この変更の目標といくつかの副作用についてしか推測できません。私の調査結果のいずれかが正しくない場合は、私に知らせてください。

タイマーの中断とその理由

まず、オペレーティングシステムの設計について少し説明します。プログラムが眠りに落ち、後で目を覚ますことができることが望ましい。実際、これはあまり頻繁に行うべきではありません-スレッドは通常、タイマーではなくイベントを待機します-しかし、必要な場合もあります。したがって、Windowsにはスリープ機能 があります。必要なスリープ時間をミリ秒単位で渡すと、プロセスがウェイクアップします。



スリープ（1）;



これがどのように実装されているかを検討する価値があります。理想的には、Sleep（1）が呼び出されると、プロセッサはスリープ状態になります。しかし、プロセッサがスリープ状態の場合、オペレーティングシステムはどのようにスレッドをウェイクアップしますか？答えはハードウェア割り込みです。 OSはチップ（ハードウェアタイマー）をプログラムします。ハードウェアタイマーは、プロセッサをウェイクアップする割り込みをトリガーし、OSはスレッドを開始します。



WaitForSingleObject関数とWaitForMultipleObjects関数にもタイムアウト値があり、これらのタイムアウトは同じメカニズムを使用して実装されます。



タイマーを待機しているスレッドが多数ある場合、OSはスレッドごとに個別の時間にハードウェアタイマーをプログラムできますが、これは通常、スレッドがランダムな時間にウェイクアップし、プロセッサが正常にスリープしないという事実につながります。 CPUの電力効率は、スリープ時間（通常の時間は8ms）に大きく依存し、ランダムウェイクはこれに寄与しません。複数のスレッドがタイマーの期待値を同期またはプールすると、システムのエネルギー効率が向上します。



ウェイクを組み合わせる方法はたくさんありますが、Windowsの主なメカニズムは、一定の速度で刻々と変化するタイマーをグローバルに中断することです。スレッドがSleep（n）を呼び出すと、OSは最初のタイマー割り込みの直後にスレッドが開始するようにスケジュールします。つまり、スレッドは少し遅れてウェイクアップする可能性がありますが、WindowsはリアルタイムOSではなく、特定のウェイクアップ時間を保証するものではありません（この時点ではプロセッサコアがビジーである可能性があります）。したがって、少し遅れてウェイクアップするのはごく普通のことです。



タイマー割り込みの間隔は、Windowsとハードウェアのバージョンによって異なりますが、すべてのマシンでデフォルトで15.625ms（1000ms / 64）になっています。これは、Sleep（1）を呼び出すとあるランダムな時間に、次のグローバルタイマー割り込みがトリガーされたとき（または早すぎる場合は1回後）、プロセスは将来1.0msから16.625msの間のどこかでウェイクアップされます。



つまり、タイマー遅延の性質は、（プロセッサーのアクティブ待機が使用されている場合を除き、使用しないでください）、OSはタイマー割り込みを使用して特定の時間にのみスレッドをウェイクアップでき、Windowsは通常の割り込みを使用します。



一部のプログラム（WPF、SQL Server、Quartz、PowerDirector、Chrome、Go Runtime、多くのゲームなど）では、待ち時間にそれほど大きなばらつきはありません。幸い、timeBeginPeriod関数で問題を修正できますこれにより、プログラムはより短い間隔を要求できます。間隔を1ミリ秒未満に設定できるNtSetTimerResolution関数もありますが、使用されることはめったになく、必要になることもないため、ここでは再度説明しません。

狂気の数十年

これはおかしなことです。timeBeginPeriodはどのプログラムからでも呼び出すことができ、タイマー割り込み間隔を変更します。タイマー割り込みはグローバルリソースです。



プロセスAがSleep（1）の呼び出しとループしていると想像してみましょう。これは間違っていますが、そうであり、デフォルトでは、15.625msごと、つまり1秒間に64回ウェイクアップします。次に、プロセスBが入り、timeBeginPeriod（2）を呼び出します。これにより、タイマーがより頻繁に起動し、プロセスAが毎秒64回ではなく、毎秒500回ウェイクアップします。これは狂気です！しかし、これはWindowsが常に機能してきた方法です。



この時点で、プロセスCが表示され、timeBeginPeriod（4）が呼び出された場合、それは何も変更しません-プロセスAは1秒間に500回ウェイクアップし続けます。このような状況では、ルールを設定するのは最後の呼び出しではなく、最小間隔の呼び出しです。



したがって、実行中のプログラムからtimeBeginPeriodを呼び出すと、グローバルタイマーの割り込み間隔を設定できます。このプログラムが終了するか、timeEndPeriodを呼び出すと、新しい最小値が有効になります。 1つのプログラムがtimeBeginPeriod（1）を呼び出す場合、これはシステム全体のタイマー割り込み間隔になります。 1つのプログラムがtimeBeginPeriod（1）を呼び出し、別のプログラムがtimeBeginPeriod（4）を呼び出す場合、1ミリ秒のタイマー割り込み間隔は普遍的な法則になります。



ここで説明するように、高いタイマー割り込みレート（およびそれに関連する高いスレッドスケジューリングレート）は、CPUパワーを大幅に浪費する可能性があるため、これは重要です。



タイマーベースのスケジューリングが必要なアプリケーションの1つは、Webブラウザーです。 JavaScript標準には、数ミリ秒後にJavaScript関数を呼び出すようにブラウザーに要求するsetTimeout関数があります。 Chromiumはタイマーを使用して、この機能やその他の機能を実装します（基本的に、Sleepではなくタイムアウト付きのWaitForSingleObject）。多くの場合、これにはタイマーの割り込み率を上げる必要があります。バッテリー寿命を低く保つために、Chromiumは最近、バッテリー電源でタイマー割り込みレートを125 Hz（8ms間隔）未満に保つように再設計されました。

timeGetTime

timeGetTime 関数（GetTickCountと混同しないでください）は、タイマー割り込みによって更新された現在の時刻を返します。プロセッサは、歴史的に正確な時刻を維持するのがあまり得意ではありませんでした（FM送信機としての機能を回避するために、およびその他の理由で、それらのクロックは意図的に振動します）。そのため、CPUは、正確な時刻を維持するために別個のクロックジェネレータに依存することがよくあります。これらのチップからの読み取りにはコストがかかるため、Windowsはタイマー割り込みで更新された64ビットミリ秒カウンターを維持します。このタイマーは共有メモリに保存されるため、どのプロセスでも、時計に行かなくても、そこから現在の時刻を安価に読み取ることができます。timeGetTimeはReadInterruptTickを呼び出します。これは、基本的にこの64ビットカウンターを読み取るだけです。とても簡単です！



カウンタはタイマー割り込みによって更新されるため、それを追跡してタイマー割り込み頻度を見つけることができます。

文書化されていない新しい現実

Windows 10 2004のリリース（2020年4月）により、これらのメカニズムの一部がわずかに変更されましたが、非常に紛らわしい方法です。まず、timeBeginPeriodが機能しなくなったというメッセージがありました。実際、すべてがはるかに複雑であることが判明しました。



最初の実験では、さまざまな結果が得られました。timeBeginPeriod（2）を呼び出してプログラムを実行すると、clockresは2.0msのタイマー間隔を示しましたが、Sleep（1）ループを備えた別のテストプログラムは、以前のバージョンのWindowsの500回ではなく、1秒あたり約64回起動しました。

科学実験

次に、システムの動作を研究するためのプログラムをいくつか作成しました。1つのプログラム（change_interval.cpp）はループ内にあり、1〜15ミリ秒の間隔でtimeBeginPeriodを呼び出します。彼女は各間隔を4秒間保持してから、次の間隔に移動します。15行のコード。簡単。



別のプログラム（measure_interval.cpp）は、change_interval.cppが変更されたときにその動作がどのように変化するかを確認するために、いくつかのテストを実行します。プログラムは3つのパラメータを監視します。

1. 彼女はOSに、NtQueryTimerResolutionを使用しているグローバルタイマーの現在の解像度を尋ねます。
   
   
2. timeGetTime, ,  — , .
   
   
3. Sleep(1), . .

@FelixPetriconiはWindows10 1909でテストを実行し、Windows 10 2004でテストを実行しました。ジッタのない結果は次のとおりです。







これは、timeBeginPeriodがすべてのWindowsバージョンでグローバルタイマー間隔を設定することを意味します。timeGetTime（）の結果から、少なくとも1つのプロセッサコアでこのレートで割り込みがトリガーされ、時刻が更新されていると言えます。 1909年の最初の行の2.0もWindowsXPでは2.0、次にWindows 7/8では1.0でしたが、再び2.0に戻ったようです。



ただし、Windows 10 2004では、スケジューリングの動作が大幅に変更されます。以前は、スリープの遅延（1）timeBeginPeriod（1）を除いて、どのプロセスでもタイマーの割り込み間隔と同じで、次のようなグラフが表示され







ます。Windows10 2004では、timeBeginPeriodと別のプロセス（timeBeginPeriodを呼び出さなかった）のスリープレイテンシとの関係は奇妙に見え







ます。グラフの左側の正確な形状は不明ですが、それは間違いなく前のものとは反対の方向に進みます！



どうして？

効果

redditとhacker-newsの議論で指摘されているように、グローバルタイマー割り込みの利用可能な精度を考えると、グラフの左半分は「通常の」遅延を可能な限り模倣しようとしている可能性があります。つまり、6ミリ秒の割り込み間隔では、遅延は約12ミリ秒（2サイクル）発生し、7ミリ秒の割り込み間隔では、約14ミリ秒（2サイクル）遅延します。ただし、実際の遅延を測定すると、現実はさらに混乱することがわかります。タイマー割り込みが7msに設定されている場合、14msのスリープ（1）待ち時間は、最も一般的な結果ではありません。







一部のリーダーは、システムのランダムノイズを非難する場合がありますが、タイマー割り込みレートが9ms以上の場合、ノイズはゼロであるため、そうではありません。説明かもしれません。更新したコードを自分で実行してみてください。 4msから8msまでのタイマー割り込み間隔は特に物議を醸しているようです。現在のコードはスケジューリングルールの変更とタイマーの精度の変更によってランダムに影響を受けるため、間隔の測定はおそらくQueryPerformanceCounterを使用して実行する必要があります。



これはすべて非常に奇妙で、ロジックや実装がわかりません。これは間違いかもしれませんが、私はそれを疑っています。この背後には複雑な後方互換性ロジックがあると思います。ただし、互換性の問題を回避する最も効果的な方法は、できれば事前に変更を文書化することです。ここでは、通知なしに編集が行われます。



これはほとんどのプログラムに影響しません。プロセスがより高速なタイマー中断を必要とする場合は、timeBeginPeriod自体を呼び出す必要があります。..。ただし、次の問題が発生する可能性があります。

• プログラムは、Sleep（1）とtimeGetTimeの解像度が同じであると誤って想定する可能性がありますが、これはもはや当てはまりません。しかし、そのような仮定はありそうもないようです。
  
  
• , .  — Windows System Timer Tool TimerResolution 1.2. «» , . , . , , .
  
  
• , , . , . . , , timeBeginPeriod , , .

change_interval.cpp テストプログラムは、誰もより高いタイマー割り込みレートを要求しない場合にのみ機能します。ChromeとVisualStudioはどちらもこれを行う習慣があるため、インターネットにアクセスしたりメモ帳にコーディングしたりせずに、ほとんどの実験を行う必要がありました。誰かがEmacsを提案しましたが、この議論に参加することは私の力を超えています。