為Windows實現一個連續更新，高精度的時間供應器

本篇文章假定你熟悉 C++ 和 Win32 API

概要

從 Windows NT 裡獲得的時間戳記（Timestamp），根據你所使用的硬體，其最大精度為 10 到 15 毫秒。但是， 有時候你需要時間標籤頻繁事件時，獲得更高的精度更能令人滿意。舉個例子，如果你要與線程打交道，或者以間隔不低於 10 毫秒的頻率實現某些其它任務時該怎麼辦？為了獲得更好的精度，建議的方法包括使用效能計數器和系統時間一起去計算更小的時間增量。然而使用效能計數器技術有其自身的問題。本文將揭示一種可行的途徑來克服該方法固有的局限。

你為什麼會對獲得小於1毫秒精度的系統時間感興趣？在我工作期間，我發現有必要去確定我的進程裡不同線程執行引發的事件的順序。還需要把這些事件同絕對時間相 關聯，但注意到系統時間的實際精度是不會超過10毫秒粒度的。

在本文隨後的內容中，我將解釋該系統時間精度的限制，解決的步驟，以及某些一般缺陷。例子程式的實現可以從本文開始連結處下載。這些檔案的原始碼是在 Visual C++? 7.1 和 Windows? XP 專業版下編寫測試的。在編寫本文時，我頻繁地提到 Windows NT® 作業系統家族（Windows NT 4.0, Windows 2000, 或者 Windows XP)產品，而不是某一個特定的版本。 本文中用到的 Win32? APIs 的參數類型及用法，參見 MSDN library/Platform SDK 文檔。

究竟誰有這樣的需求？

最近我用“Windows NT millisecond time resolution”作為關鍵字在 Internet 上搜尋了一番, 得到了 400 多個滿足條件的結果。其中大多數是討論如何獲得高於10毫秒精度的系統時間，或者是如何讓一個線程的休眠時間小於10毫秒。本文我將專註於為什麼獲得一個高於10毫秒精度的系統時間 會如此困難。你可能認為用 GetSystemTime API 很容易解決問題，這個 API 函數返回一個SYSTEMTIME 結構，該結構包含一個 wMilliseconds 域，在 MSDN 文檔中說它儲存 當前的毫秒時間。但實際上並不象這麼簡單。那麼用 GetSystemTimeAsFileTime 擷取 100 納秒的精度如何呢？就讓我們從一個小實驗 開始吧：嘗試重複擷取系統時間，將它格式化並輸出到螢幕上（見 Figure 1 ）。

我的目標不是納秒，而僅是毫秒精度，它應該能夠從 SYSTEMTIME 結構中判斷。讓我們看一下輸出結果：

20:12:23.479
20:12:23.479
20:12:23.494
20:12:23.494
[...有很多被移去了...]
20:12:23.494
20:12:23.509
20:12:23.509
20:12:23.509
...

正如你所看到的，我所能得到的最好的精度是15毫秒，這是 Windows NT 刻度的長度。每過一個刻度，Windows NT都會更新系統時間。Windows NT調度器也會 突然啟動並可能選擇一個新的線程來執行。關於這方面的更多資訊，請看《Inside Windows 2000》第三版(Microsoft Press®, 2000)，作者是 David Solomon 和 Mark Russinovich。

如果你運行我剛才所示的代碼，你也許會看到時間大約是每10毫秒更新一次。如果是那樣，可能意味著你是在單一處理器的機器上運行 Windows NT，其刻度通常為10毫秒。正如你所看到的， 在這種方法中，系統時間更新頻率不夠快，不足以成為一種為我所用的技術。下面我們就來嘗試找一個解決方案。

最初的嘗試

當你詢問如何得到一個比10毫秒精度更好的系統時間時，你也許會得到下面這樣的回答：使用效能計數器，並讓效能計數器值和即時變化的系統時間同步。結合這些值來計算一個 精度極高的目前時間。Figure 2 顯示了實現方法。

效能計數器是一個高精度的硬體計數器，它能高精確、低開銷地計量一個短周期時間。我通過在一個緊湊迴圈內不斷重複把效能計數器值和對應的系統時間進行同步，等待系統時間變化。當系統時間 以變，我就儲存計數器的值及系統時間。

使用這兩個值作為參考，就有可能計算出一個高精度的當前系統時間（詳情見 Figure 2 中的get_time)，看一下結果：

...
21:23:22.296
21:23:22.297
21:23:22.297
21:23:22.298
21:23:22.298
21:23:22.299
21:23:22.300
21:23:22.300
21:23:22.301
21:23:22.301
21:23:22.302
21:23:22.302
21:23:22.303
...

儘管它看起來非常成功，但這個實現卻有幾個問題：同步實現（函數被命名為 "simplistic_synchronize"的一個很好的理由）；QueryPerformanceFrequency 報告的頻率 ；系統時間變化缺乏保護。在接下來的章節中，我們會考慮這些問題的一些可能的改進。