👩🏼‍🎓 🥝 🦔 Windows：スリープ（0.5） 🛌🏻 😨 🙂

おそらく多くの人が知っているように、 スリープ状態にしたいミリ秒数は、WinAPIのSleep関数に渡されます。したがって、要求できる最小値は1ミリ秒間スリープ状態になります。しかし、さらに睡眠を減らしたい場合はどうでしょうか？写真でこれを行う方法に興味がある人は、猫の下で歓迎します。

まず、Windowsは（他の非リアルタイムシステムと同様に）スレッド（スレッドと呼ばれることもある）が要求された時間に正確にスリープすることを保証しないことを思い出します。 Vista以降、OSのロジックは単純です。実行のためにスレッドに割り当てられた一定の時間があります（はい、はい、2000 / XPの間に誰もが聞いたのと同じ20ミリ秒であり、それでもサーバーの軸でそれを聞きます）また、Windowsは、このクォンタムが期限切れになった後にのみ、スレッドを再スケジュール（一部のスレッドを停止、他のスレッドを開始）します。つまり OSのクォンタムが20ミリ秒（XPのデフォルトはそのような値など）である場合、 スリープ（1）を要求したとしても、最悪の場合、同じ20ミリ秒後に制御が返されます。この時間単位、特にtimeBeginPeriod / timeEndPeriodを管理するためのマルチメディア機能があります。

第二に、このような正確さが必要な理由を簡単に説明します。 Microsoftは、このような精度が必要なのはマルチメディアアプリケーションだけだと言います。たとえば、blackjetを使用して新しいWinAMPを作成します。ここでは、新しいオーディオデータを時間通りにシステムに送信することが非常に重要です。私のニーズは別の分野にありました。 H264ストリームデコンプレッサーがありました。そして彼はffmpeg'eにいた。そして、彼は同期インターフェース（Frame * decompressor.Decompress（Frame * compressedFrame））を持っていました。そして、プロセッサのIntelチップで解凍を行うまで、すべてが順調でした。ちなみに、ネイティブIntel Media SDKではなく、DXVA2インターフェイスを使用して作業する必要があった理由を覚えていません。そして、それは非同期です。だから私はこのように働かなければなりませんでした：

データをビデオメモリにコピーする
フレームがリラックスする時間を持つように、スリープ状態にします
解凍が完了したかどうかを確認し、完了している場合は、ビデオメモリから拡張フレームを取得します

問題は2番目の段落にありました。 GPUViewを信じている場合、フレームには50〜200マイクロ秒で解凍する時間がありました。 Sleep（1）を設定すると、コアi5で最大1000 * 4 *（コア）= 4000フレーム/秒を解凍できます。通常のfpsが25に等しいと考えると、これは同時に40 * 4 = 160のビデオストリームのみを解凍します。そして目標は200を引き出すことでした。実際には2つのオプションがありました。ハードウェアコンプレッサーを使用して非同期操作のためにすべてをやり直すか、スリープ時間を短縮するかです。

最初の測定

現在の実行時のクォンタムを概算するために、簡単なプログラムを作成します。

void test() { std::cout << "Starting test" << std::endl; std::int64_t total = 0; for (unsigned i = 0; i < 5; ++i) { auto t1 = std::chrono::high_resolution_clock::now(); ::Sleep(1); auto t2 = std::chrono::high_resolution_clock::now(); auto elapsedMicrosec = std::chrono::duration_cast<std::chrono::microseconds>(t2 - t1).count(); total += elapsedMicrosec; std::cout << i << ": Elapsed " << elapsedMicrosec << std::endl; } std::cout << "Finished. average time:" << (total / 5) << std::endl; } int main() { test(); return 0; }

Win 8.1の典型的な出力を次に示します

開始テスト
0：1977年の経過
1：経過1377
2：経過1409
3：経過1396
4：経過1432
完成した平均時間：1518

すぐに、たとえばMSVS 2012がある場合、std :: chrono :: high_resolution_clockを使用するつもりはないことを警告します。とにかく、何かの継続時間を測定する最も確実な方法は、パフォーマンスカウンターを使用することです。コードを少し書き直して、正しい時間を測定していることを確認します。最初に、クラスヘルパーを記述します。 _{私は現在MSVS2015でテストを行いましたが、そこではhigh_resolution_clockの実装はパフォーマンスカウンターを通じて既に正しいです。} _{私はこのステップをやっている、突然誰かが古いコンパイラでテストを繰り返したい}

PreciseTimer.h

 #pragma once class PreciseTimer { public: PreciseTimer(); std::int64_t Microsec() const; private: LARGE_INTEGER m_freq; //   . }; inline PreciseTimer::PreciseTimer() { if (!QueryPerformanceFrequency(&m_freq)) m_freq.QuadPart = 0; } inline int64_t PreciseTimer::Microsec() const { LARGE_INTEGER current; if (m_freq.QuadPart == 0 || !QueryPerformanceCounter(¤t)) return 0; //      . return current.QuadPart * 1000'000 / m_freq.QuadPart; }

変更されたテスト機能

 void test() { PreciseTimer timer; std::cout << "Starting test" << std::endl; std::int64_t total = 0; for (unsigned i = 0; i < 5; ++i) { auto t1 = timer.Microsec(); ::Sleep(1); auto t2 = timer.Microsec(); auto elapsedMicrosec = t2 - t1; total += elapsedMicrosec; std::cout << i << ": Elapsed " << elapsedMicrosec << std::endl; } std::cout << "Finished. average time:" << (total / 5) << std::endl; }

さて、Windows Server 2008 R2でのプログラムの典型的な出力

開始テスト
0：経過10578
1：経過14519
2：経過14592
3：経過14625
4：経過14354
完成した平均時間：13733

額の問題を解決しようとしています

プログラムを少し書き直します。そして、明白なものを使用してみてください：

std :: this_thread :: sleep_for（std ::クロノ::マイクロ秒（500））

 void test(const std::string& description, const std::function<void(void)>& f) { PreciseTimer timer; std::cout << "Starting test: " << description << std::endl; std::int64_t total = 0; for (unsigned i = 0; i < 5; ++i) { auto t1 = timer.Microsec(); f(); auto t2 = timer.Microsec(); auto elapsedMicrosec = t2 - t1; total += elapsedMicrosec; std::cout << i << ": Elapsed " << elapsedMicrosec << std::endl; } std::cout << "Finished. average time:" << (total / 5) << std::endl; } int main() { test("Sleep(1)", [] { ::Sleep(1); }); test("sleep_for(microseconds(500))", [] { std::this_thread::sleep_for(std::chrono::microseconds(500)); }); return 0; }

Windows 8.1での典型的な出力

開始テスト：スリープ（1）
0：経過1187
1：経過1315
2：経過1427
3：経過1432
4：経過1449
完成した平均時間：1362
開始テスト：sleep_for（マイクロ秒（500））
0：経過した1297
1：経過1434
2：経過1280
3：経過1451
4：経過1459
完成した平均時間：1384

つまりご覧のとおり、移動中のゲインはありません。 this_thread :: sleep_forをよく見てください 。そして、一般的にthis_thread :: sleep_until 、つまり スリープとは異なり、彼は、例えば、時計の影響も受けません。最良の代替案を見つけてみましょう。

できるスリップ

MSDNとstackoverflowを検索すると、唯一の代替手段として待機可能なタイマーに導かれます。さて、別のヘルパークラスを作成しましょう。

WaitableTimer.h

 #pragma once class WaitableTimer { public: WaitableTimer() { m_timer = ::CreateWaitableTimer(NULL, FALSE, NULL); if (!m_timer) throw std::runtime_error("Failed to create waitable time (CreateWaitableTimer), error:" + std::to_string(::GetLastError())); } ~WaitableTimer() { ::CloseHandle(m_timer); m_timer = NULL; } void SetAndWait(unsigned relativeTime100Ns) { LARGE_INTEGER dueTime = { 0 }; dueTime.QuadPart = static_cast<LONGLONG>(relativeTime100Ns) * -1; BOOL res = ::SetWaitableTimer(m_timer, &dueTime, 0, NULL, NULL, FALSE); if (!res) throw std::runtime_error("SetAndWait: failed set waitable time (SetWaitableTimer), error:" + std::to_string(::GetLastError())); DWORD waitRes = ::WaitForSingleObject(m_timer, INFINITE); if (waitRes == WAIT_FAILED) throw std::runtime_error("SetAndWait: failed wait for waitable time (WaitForSingleObject)" + std::to_string(::GetLastError())); } private: HANDLE m_timer; };

そして、新しいテストを追加します：

 int main() { test("Sleep(1)", [] { ::Sleep(1); }); test("sleep_for(microseconds(500))", [] { std::this_thread::sleep_for(std::chrono::microseconds(500)); }); WaitableTimer timer; test("WaitableTimer", [&timer] { timer.SetAndWait(5000); }); return 0; }

何が変わったのか見てみましょう。

Windows Server 2008 R2での典型的な出力

開始テスト：スリープ（1）
0：経過10413
1：経過8467
2：経過14365
3：経過14563
4：経過14389
完成した平均時間：12439
開始テスト：sleep_for（マイクロ秒（500））
0：11771を経過
1：経過14247
2：経過14323
3：経過14426
4：経過14757
完成した平均時間：13904
開始テスト：WaitableTimer
0：経過12654
1：経過14700
2：経過14259
3：経過14505
4：経過14493
完成した平均時間：14122

ご覧のとおり、外出先でのサービスオペレーションでは、何も変わっていません。デフォルトでは、その上でのフローランタイムクォンタムは通常巨大です。 XPとWindows 7を搭載した仮想マシンは探しませんが、XPでもまったく同様の状況になる可能性が高いと言えますが、Windows 7ではデフォルトの1ミリ秒のタイムスライスのようです。つまり新しいテストでは、Windows 8.1での以前のテストと同じインジケーターが提供されます。

それでは、Windows 8.1でのプログラムの出力を見てみましょう。

開始テスト：スリープ（1）
0：経過した1699
1：経過1444
2：経過1493
3：経過1482
4：経過1403
完成した平均時間：1504
開始テスト：sleep_for（マイクロ秒（500））
0：経過1259
1：経過1088
2：経過1497
3：経過1497
4：経過1528
完成した平均時間：1373
開始テスト：WaitableTimer
0：経過643
1：経過481
2：経過424
3：経過330
4：経過468
完成した平均時間：469

何が見えますか？新しいスリップができたのは事実です！つまり Windows 8.1では、すでに問題を解決しています。何が起こったのですか？これは、ウィンドウ8.1ではタイムクォンタムがわずか500マイクロ秒であったために発生しました。はい、はい、スレッドは500マイクロ秒で実行されます（私のシステムでは、デフォルトで解像度は500.8マイクロ秒に設定され、正確に500マイクロ秒を設定することができたXP / Win7とは異なり、より低く設定されていません）新しい実行で実行します。

結論1 ： 睡眠（0.5）を必要とするが、十分ではない、正しいスリップ。これには常に待機可能タイマーを使用します。

結論2 ：Win 8.1 / Win 10のみで記述し、他のOSで実行しないことが保証されている場合、Waitable Timerの使用を停止できます。

状況への依存またはシステムタイマーの精度を上げる方法を削除します

マルチメディア関数timeBeginPeriodについては既に述べました。ドキュメントには、この機能を使用して、タイマーの精度を設定できることが記載されています。見てみましょう。もう一度、プログラムを変更します。

プログラムv3

 #include "stdafx.h" #include "PreciseTimer.h" #include "WaitableTimer.h" #pragma comment (lib, "Winmm.lib") void test(const std::string& description, const std::function<void(void)>& f) { PreciseTimer timer; std::cout << "Starting test: " << description << std::endl; std::int64_t total = 0; for (unsigned i = 0; i < 5; ++i) { auto t1 = timer.Microsec(); f(); auto t2 = timer.Microsec(); auto elapsedMicrosec = t2 - t1; total += elapsedMicrosec; std::cout << i << ": Elapsed " << elapsedMicrosec << std::endl; } std::cout << "Finished. average time:" << (total / 5) << std::endl; } void runTestPack() { test("Sleep(1)", [] { ::Sleep(1); }); test("sleep_for(microseconds(500))", [] { std::this_thread::sleep_for(std::chrono::microseconds(500)); }); WaitableTimer timer; test("WaitableTimer", [&timer] { timer.SetAndWait(5000); }); } int main() { runTestPack(); std::cout << "Timer resolution is set to 1 ms" << std::endl; //     timeGetDevCaps   ,   ,      //    ,        timeBeginPeriod(1); ::Sleep(1); //      ::Sleep(1); //      runTestPack(); timeEndPeriod(1); return 0; }

伝統的に、私たちのプログラムの典型的な発見。

Windows 8.1の場合

開始テスト：スリープ（1）
0：2006年の経過
1：経過1398
2：経過1390
3：経過1424
4：経過1424
完成した平均時間：1528
開始テスト：sleep_for（マイクロ秒（500））
0：経過1348
1：経過1418
2：経過1459
3：経過1475
4：経過1503
完成した平均時間：1440
開始テスト：WaitableTimer
0：経過200
1：経過469
2：経過442
3：経過456
4：経過462
完成した平均時間：405
タイマーの解像度は1ミリ秒に設定されています
開始テスト：スリープ（1）
0：経過1705
1：経過1412
2：経過1411
3：経過1441
4：経過1408
完成した平均時間：1475
開始テスト：sleep_for（マイクロ秒（500））
0：1916年経過
1：経過1451
2：経過1415
3：経過1429
4：経過1223
完成した平均時間：1486
開始テスト：WaitableTimer
0：経過602
1：経過445
2：経過994
3：経過347
4：経過345
完成した平均時間：546

そして、Windows Server 2008 R2

開始テスト：スリープ（1）
0：経過10306
1：経過13799
2：経過13867
3：経過13877
4：経過13869
完成した平均時間：13143
開始テスト：sleep_for（マイクロ秒（500））
0：経過10847
1：経過13986
2：経過14000
3：経過13898
4：経過13834
完成した平均時間：13313
開始テスト：WaitableTimer
0：経過11454
1：経過13821
2：経過14014
3：経過13852
4：経過13837
完成した平均時間：13395
タイマーの解像度は1ミリ秒に設定されています
開始テスト：スリープ（1）
0：940を経過
1：経過218
2：経過276
3：経過352
4：経過384
完成した平均時間：434
開始テスト：sleep_for（マイクロ秒（500））
0：経過797
1：経過386
2：経過371
3：経過389
4：経過371
完成した平均時間：462
開始テスト：WaitableTimer
0：経過323
1：経過338
2：経過309
3：経過359
4：経過391
完成した平均時間：344

結果から見える興味深い事実を分析しましょう。

Windows 8.1では、何も変更されていません。 timeBeginPeriodは十分に賢い、つまり N個のアプリケーションが異なる値でシステムタイマーの解像度を要求した場合、この解像度は低下しません。 Windows 7では、タイマーの解像度が既に1ミリ秒であるため、変更も認識されません。
サーバーOSでは、 timeBeginPeriod（1）は予期しない方法で動作しました。システムタイマーの解像度を可能な限り高い値に設定しました。つまりそのようなOSでは、フォームの回避策が明らかに縫い付けられています：
```
 void timeBeginPerion(UINT uPeriod) { if (uPeriod == 1) { setMaxTimerResolution(); return; } ... } 
```
これは、Windows Server 2003 R2ではこれまで発生していなかったことに注意してください。これは2008サーバーの革新です。
サーバーOSでは、 Sleep（1）も予期しない方法で動作しました。つまり スリープ（1）は 、 サーバーOSでは2008サーバーから 「 1ミリ秒の一時停止 」ではなく「 できる限り最小の一時停止 」として解釈されます。 ^{この場合、この記述が正しくない場合があります。}

結論を続けましょう。

結論3 ：Win Server 2008/2012/2016でのみ記述し、他のOSで実行しないことが保証されている場合、気にする必要はまったくありません。timeBeginPeriod（1）とそれに続くSleep（1）が必要なすべてを行います。

結論4 ：私たちの目的のためのtimeBeginPeriodは、サーバー軸に対してのみ有効です。ただし、Waitableタイマーと共有すると、Win Server 2008/2012/2016およびWindows 8.1 / Windows 10でのタスクがカバーされます。

一度にすべてが必要な場合はどうなりますか？

Windows XP / Windows Vista / Windows 7 / Windows Server 2003でスリープ（0.5）が必要な場合の対処方法を考えてみましょう。

ネイティブAPIのみが助けになります-ntdll.dllを介してユーザー空間からアクセスできる、文書化されていないAPIです。興味深いNtQueryTimerResolution / NtSetTimerResolution関数があります。

AdjustSystemTimerResolutionTo500mcs関数を作成します。

 ULONG AdjustSystemTimerResolutionTo500mcs() { static const ULONG resolution = 5000; // 0.5   100- . ULONG sysTimerOrigResolution = 10000; ULONG minRes; ULONG maxRes; NTSTATUS ntRes = NtQueryTimerResolution(&maxRes, &minRes, &sysTimerOrigResolution); if (NT_ERROR(ntRes)) { std::cerr << "Failed query system timer resolution: " << ntRes; } ULONG curRes; ntRes = NtSetTimerResolution(resolution, TRUE, &curRes); if (NT_ERROR(ntRes)) { std::cerr << "Failed set system timer resolution: " << ntRes; } else if (curRes != resolution) { //        curRes  resolution,   . ..  , , //   5000,    5008 std::cerr << "Failed set system timer resolution: req=" << resolution << ", set=" << curRes; } return sysTimerOrigResolution; }

コードをコンパイルするには、必要な関数の宣言を追加します。

 #include <winnt.h> #ifndef NT_ERROR #define NT_ERROR(Status) ((((ULONG)(Status)) >> 30) == 3) #endif extern "C" { NTSYSAPI NTSTATUS NTAPI NtSetTimerResolution( _In_ ULONG DesiredResolution, _In_ BOOLEAN SetResolution, _Out_ PULONG CurrentResolution); NTSYSAPI NTSTATUS NTAPI NtQueryTimerResolution( _Out_ PULONG MaximumResolution, _Out_ PULONG MinimumResolution, _Out_ PULONG CurrentResolution); } #pragma comment (lib, "ntdll.lib")

Windows 8.1での典型的な出力

開始テスト：スリープ（1）
0：経過13916
1：経過14995
2：経過3041
3：経過2247
4：経過15141
完成した平均時間：9868
開始テスト：sleep_for（マイクロ秒（500））
0：経過12359
1：経過14607
2：経過15019
3：経過14957
4：経過14888
完成した平均時間：14366
開始テスト：WaitableTimer
0：経過した12783
1：経過14848
2：経過14647
3：経過14550
4：経過14888
完成した平均時間：14343
タイマーの解像度は1ミリ秒に設定されています
開始テスト：スリープ（1）
0：経過1175
1：経過1501
2：経過1473
3：経過1147
4：経過1462
完成した平均時間：1351
開始テスト：sleep_for（マイクロ秒（500））
0：経過1030
1：経過1376
2：経過1452
3：経過1335
4：経過1467
完成した平均時間：1332
開始テスト：WaitableTimer
0：経過105
1：経過394
2：経過429
3：経過927
4：経過505
完成した平均時間：472

Windows Server 2008 R2での典型的な出力

開始テスト：スリープ（1）
0：7364を経過
1：経過14056
2：経過14188
3：経過13910
4：経過14178
完成した平均時間：12739
開始テスト：sleep_for（マイクロ秒（500））
0：経過11404
1：経過13745
2：経過13975
3：経過14006
4：経過14037
完成した平均時間：13433
開始テスト：WaitableTimer
0：経過11697
1：経過14174
2：経過13808
3：14010経過
4：経過した14054
完成した平均時間：13548
タイマーの解像度は1ミリ秒に設定されています
開始テスト：スリープ（1）
0：経過10690
1：経過14308
2：経過768
3：経過823
4：経過803
完成した平均時間：5478
開始テスト：sleep_for（マイクロ秒（500））
0：経過した983
1：経過955
2：経過946
3：経過937
4：経過946
完成した平均時間：953
開始テスト：WaitableTimer
0：経過259
1：経過456
2：経過453
3：経過456
4：経過460
完成した平均時間：416

観察と結論を出すことは残っています。

観察：

Win8では、プログラムの最初の起動後、システムタイマーの解像度が大きな値にリセットされました。つまり 結論2は、私たちが間違っていました。
手動インストール後、平均スリップは約500マイクロ秒ですが、WaitableTimerケースの実際のスリップの広がりが増加しました。
サーバーOSでは、 timeBeginPeriodの場合と比較して、 Sleep（1）は非常に予期せず動作を停止しました（ this_thread :: sleep_forなど ）。つまり スリープ（1）は正常に機能し始めました。つまり、「 1ミリ秒間一時停止します」。

最終的な結論

結論1に変更はありませんでした。 睡眠（0.5）が必要ですが、十分ではないため、正しいスリップが必要です。これには常に待機可能タイマーを使用します。
結論2 ：Windowsのシステムタイマーの解像度は、Windowsの種類、Windowsのバージョン、現在実行中のプロセス、前に実行できるプロセスによって異なります。つまり何も主張も保証もできません！保証が必要な場合は、必要な精度を常に要求/設定する必要があります。 1ミリ秒未満の値の場合、ネイティブAPIを使用する必要があります。値が大きい場合は、 timeBeginPeriodを使用することをお勧めします。
結論3 ：可能であれば、作業中のWin 10だけでなく、主要な顧客から指示されたコードでもテストすることをお勧めします。サーバーOSはデスクトップとは大きく異なる可能性があることに注意してください