這一篇講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++深入研究後再來解釋。

1. 按照英文註釋，qpc乘以1e6後過大，再除以一個數時會溢位。但是下面的那個方法用的是1個溢位數加上1個小整數，為啥這樣就不會出問題。難道加減不存在threshold？
2. 那個計算誤差是我理解的，實際上如果上過小學，把上面的變數代入第二個算式，會得到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舉例子，記憶體結構如下所示。

　　整個過程大概是這樣的。

1. 每次獲取timeGetTime的值，只獲取頭8位的值now_8。
2. 判斷now_8是否小於union裡面儲存的last_8，如果小了(從1111...1111變成000...1)，說明時間重置了，將重置次數+1。
3. 替換last_8為新獲取的now_8。
4. 判斷當前整個整數是否與上一次獲取時相同(涉及多執行緒操作)，相同的話直接返回輸出結果。

　　最後返回值的計算也很簡單了，就是重置次數rollovers乘以重置一次的時間2^32，加上當前獲取的now，得到總的硬體時間戳。

　　完事