這一篇講windows系統下TimeTicks的實現。
對於tick,V8寫了相當長的一段discussion來討論windows系統上計數的三種實現方法以及各自的優劣,註釋在time.cc的572行,這裡直接簡單翻譯一下,不貼出來了。
CPU cycle counter.(Retrieved via RDTSC)
CPU計數器擁有最高的解析度,消耗也是最小的。然而,在一些老的CPU上會有問題;1、每個處理器獨立唯一各自的tick,並且處理器之間不會同步資料。2、計數器會因為溫度、功率等原因頻繁變化,有些情況甚至會停止。
QueryPerformanceCounter (QPC)
QPC計數法就是之前libuv用的API,解析度也相當的高。比起CPU計數器,優點就是不存在多處理器有多個tick,保證資料的唯一。但是在老的CPU上,也會因為BIOS、HAL而出現一些問題。
System Time
通過別的windowsAPI返回的系統時間來計數。
上一篇Clock類的建構函式中,對TimeTicks屬性的初始化也只是呼叫了老TimeTicks的Now方法,所以直接上Now的程式碼。
TimeTicks InitialTimeTicksNowFunction(); using TimeTicksNowFunction = decltype(&TimeTicks::Now); TimeTicksNowFunction g_time_ticks_now_function = &InitialTimeTicksNowFunction; TimeTicks TimeTicks::Now() { TimeTicks ticks(g_time_ticks_now_function()); DCHECK(!ticks.IsNull()); return ticks; }
windows系統下,會預先一個初始化方法,這裡的語法不用去理解,只需要知道呼叫InitialTimeTicksNowFunction方法後,將其返回作為引數構造一個TimeTicks物件,返回的就是硬體時間戳。
這個方法比較簡單,如下。
TimeTicks InitialTimeTicksNowFunction() { InitializeTimeTicksNowFunctionPointer(); return g_time_ticks_now_function(); }
可以看到,那個g_time_ticks_now_function又被呼叫了一次,但是作為一個函式指標,第二次呼叫的時候指向的就不是同一個方法。至於為什麼特意弄一個函式指標,後面會具體解釋。
看這裡的第一個方法。
void InitializeTimeTicksNowFunctionPointer() { LARGE_INTEGER ticks_per_sec = {}; if (!QueryPerformanceFrequency(&ticks_per_sec)) ticks_per_sec.QuadPart = 0; // 如果windows不支援QPC或者該方法不可靠 會降級去使用低解析度的lowB方法 TimeTicksNowFunction now_function; CPU cpu; // QPC不好使的情況 if (ticks_per_sec.QuadPart <= 0 || !cpu.has_non_stop_time_stamp_counter() || IsBuggyAthlon(cpu)) { now_function = &RolloverProtectedNow; } // 好使的情況 else { now_function = &QPCNow; } // 這裡不需要擔心多執行緒問題 因為更改的都是同一個全域性變數 g_qpc_ticks_per_second = ticks_per_sec.QuadPart; // 先不管這個 不然講不完 ATOMIC_THREAD_FENCE(memory_order_release); g_time_ticks_now_function = now_function; }
從幾個賦值可以看到,整個函式都是圍繞著函式指標now_function的指向,其實也就是g_time_ticks_now_function,根據系統對QPC的支援,來選擇不同的方法實現TimeTicks。
所以,特意用一個函式指標來控制Now方法的目的也明顯了,理論上只有第一次呼叫會進到這個特殊函式,檢測當前作業系統的QPC是否適用,然後選擇對應的方法。後面再次呼叫的時候,就直接進入選好的方法(具體思想可以參考《JavaScript高階程式設計》高階技巧章節的惰性載入函式)。這個情況有一點像我在解析node事件輪詢時提到的執行緒池初始化情形,不同的是,這裡V8沒有特意去加一個鎖來防止多執行緒競態。原因也很簡單,因為此處只是對一個全域性的函式指標做賦值,就算多賦值幾次對後續的執行緒並沒有任何影響,沒有必要特意做鎖。
關於QueryPerformanceFrequency方法(這些函式名都好TM長)的具體用法,可以參考我別的部落格,啥都解釋寫不完啦。
存在兩種情況的實現,先看支援QPC的,刪掉了合法性檢測巨集,這些巨集無處不在,太礙眼了。
TimeTicks QPCNow() { return TimeTicks() + QPCValueToTimeDelta(QPCNowRaw()); } V8_INLINE uint64_t QPCNowRaw() { LARGE_INTEGER perf_counter_now = {}; // According to the MSDN documentation for QueryPerformanceCounter(), this // will never fail on systems that run XP or later. // https://msdn.microsoft.com/library/windows/desktop/ms644904.aspx // 這裡說理論上XP以後的系統都支援QPC BOOL result = ::QueryPerformanceCounter(&perf_counter_now); return perf_counter_now.QuadPart; } // To avoid overflow in QPC to Microseconds calculations, since we multiply // by kMicrosecondsPerSecond, then the QPC value should not exceed // (2^63 - 1) / 1E6. If it exceeds that threshold, we divide then multiply. static constexpr int64_t kQPCOverflowThreshold = INT64_C(0x8637BD05AF7); TimeDelta QPCValueToTimeDelta(LONGLONG qpc_value) { // 這裡的if/else邏輯見上面靜態變數的註釋 也可以看我下面翻譯的 // 理論上的計算公式是 (qpc_count * 1e6) / qpc_count_per_second 得到微秒單位的硬體時間戳 // 但是int64型別最大隻能處理2^63 - 1 而這個windowsAPI返回的數字(換算乘以1e6後)可能超過這個範圍 // 如果數字過大 就用先除再乘的方式計算避免溢位 // 正常情況 if (qpc_value < TimeTicks::kQPCOverflowThreshold) { return TimeDelta::FromMicroseconds( qpc_value * TimeTicks::kMicrosecondsPerSecond / g_qpc_ticks_per_second); } // 溢位情況 // 先除得到一個秒單位的時間戳 int64_t whole_seconds = qpc_value / g_qpc_ticks_per_second; // 計算誤差 int64_t leftover_ticks = qpc_value - (whole_seconds * g_qpc_ticks_per_second); // 用當前+誤差得到最終的微秒單位時間戳 return TimeDelta::FromMicroseconds( (whole_seconds * TimeTicks::kMicrosecondsPerSecond) + ((leftover_ticks * TimeTicks::kMicrosecondsPerSecond) / g_qpc_ticks_per_second)); }
直接看註釋就好了,不過我有一些問題,先記錄下來,後面對C++深入研究後再來解釋。
- 按照英文註釋,qpc乘以1e6後過大,再除以一個數時會溢位。但是下面的那個方法用的是1個溢位數加上1個小整數,為啥這樣就不會出問題。難道加減不存在threshold?
- 那個計算誤差是我理解的,實際上如果上過小學,把上面的變數代入第二個算式,會得到leftover_ticks為0,這裡的邏輯暫時沒理清。
總之,最後還是利用了QPC的兩個API得到硬體時間戳,跟libuv的套路差不多。
下面來看不支援QPC的情況,不過先過一下那個if。
CPU cpu; if (ticks_per_sec.QuadPart <= 0 || !cpu.has_non_stop_time_stamp_counter() || IsBuggyAthlon(cpu)) { now_function = &RolloverProtectedNow;
有三個條件表明QPC不適用。
第一個很直白,API在當前作業系統不支援。
第二個是通過CPU判斷QPC是否可靠,具體原理十分麻煩,有興趣單獨開一篇解釋吧。
第三個就比較簡單,有些牌子的CPU就是垃圾,直接根據內建API返回的引數判斷是不是不支援的型別,如下。
bool IsBuggyAthlon(const CPU& cpu) { // On Athlon X2 CPUs (e.g. model 15) QueryPerformanceCounter is unreliable. return strcmp(cpu.vendor(), "AuthenticAMD") == 0 && cpu.family() == 15; }
正式進入QPC不支援分支。
union LastTimeAndRolloversState { // 完整的32位時間 int32_t as_opaque_32; struct { // 時間頭8位 uint8_t last_8; // 時間重置次數 uint16_t rollovers; } as_values; }; TimeTicks RolloverProtectedNow() { // 見上面的解釋 LastTimeAndRolloversState state; DWORD now; // DWORD is always unsigned 32 bits. // 這是一個原子運算元 執行緒安全 int32_t original = g_last_time_and_rollovers.load(std::memory_order_acquire); while (true) { // 型別為int32位整數 state.as_opaque_32 = original; // 定義如下 實際上就是windowsAPI的timeGetTime // DWORD timeGetTimeWrapper() { return timeGetTime(); } // DWORD (*g_tick_function)(void) = &timeGetTimeWrapper; now = g_tick_function(); // 移位後只獲取頭8位 uint8_t now_8 = static_cast<uint8_t>(now >> 24); // 當頭8位的時間比儲存的要小時 說明返回值重置了 if (now_8 < state.as_values.last_8) ++state.as_values.rollovers; state.as_values.last_8 = now_8; // 當兩次相同時 代表當前的值是穩定可信的 直接返回 if (state.as_opaque_32 == original) break; if (g_last_time_and_rollovers.compare_exchange_weak( original, state.as_opaque_32, std::memory_order_acq_rel)) { break; } } // 返回次數 * 2^32 加上 當前時間 return TimeTicks() + TimeDelta::FromMilliseconds( now + (static_cast<uint64_t>(state.as_values.rollovers) << 32)); }
這塊的內容相當多,首先需要解釋一下上面的核心方法timeGetTime,官網的解釋如下。
The timeGetTime function retrieves the system time, in milliseconds. The system time is the time elapsed since Windows was started.(檢測系統啟動後所經過的毫秒數)
The return value wraps around to 0 every 2^32 milliseconds, which is about 49.71 days.(返回值會從0一直漲到2^32,然後又從0開始無限迴圈)
上面的第二段表明了為什麼要用那麼複雜的處理,因為這個返回值不是無限變大,而是會重置為0。而且union這個東西也很有意思,JS裡面找不到對比的資料型別,類似於struct結構體,但不同點是記憶體共用。拿原始碼中的union舉例子,記憶體結構如下所示。
整個過程大概是這樣的。
- 每次獲取timeGetTime的值,只獲取頭8位的值now_8。
- 判斷now_8是否小於union裡面儲存的last_8,如果小了(從1111...1111變成000...1),說明時間重置了,將重置次數+1。
- 替換last_8為新獲取的now_8。
- 判斷當前整個整數是否與上一次獲取時相同(涉及多執行緒操作),相同的話直接返回輸出結果。
最後返回值的計算也很簡單了,就是重置次數rollovers乘以重置一次的時間2^32,加上當前獲取的now,得到總的硬體時間戳。
完事了。