深刻V8引擎-Time核心方法之win篇(2)

時間  2019-11-12
標籤 深刻 v8 引擎 time 核心 方法 win 简体版
原文   原文鏈接

　　這一篇講windows系統下TimeTicks的實現。html

　　對於tick，V8寫了至關長的一段discussion來討論windows系統上計數的三種實現方法以及各自的優劣，註釋在time.cc的572行，這裏直接簡單翻譯一下，不貼出來了。node

CPU cycle counter.(Retrieved via RDTSC)windows

　　CPU計數器擁有最高的分辨率，消耗也是最小的。然而，在一些老的CPU上會有問題；一、每一個處理器獨立惟一各自的tick，而且處理器之間不會同步數據。二、計數器會由於溫度、功率等緣由頻繁變化，有些狀況甚至會中止。安全

QueryPerformanceCounter (QPC)多線程

　　QPC計數法就是以前libuv用的API，分辨率也至關的高。比起CPU計數器，優勢就是不存在多處理器有多個tick，保證數據的惟一。可是在老的CPU上，也會由於BIOS、HAL而出現一些問題。app

System Timeide

　　經過別的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對象，返回的就是硬件時間戳。ui

　　這個方法比較簡單，以下。

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_value已是大於那個臨界值了，可是測試了一下也感受溢出跟加減沒啥區別，以下。

static constexpr int64_t kQPCOverflowThreshold = INT64_C(0x8637BD05AF7);

int main()
{
    LARGE_INTEGER a,b;
    QueryPerformanceCounter(&a);
    QueryPerformanceFrequency(&b);
    LONGLONG qpc = a.QuadPart;
    INT64 qpc_per = b.QuadPart;
    bool bl = qpc < kQPCOverflowThreshold;
    // 0
    cout << bl << endl;
    // 927641572774
    cout << int64_t(a.QuadPart * 1e6 / b.QuadPart) << endl;

    int64_t w = qpc / qpc_per;
    int64_t l = qpc - (w * qpc_per);
    // 927641572774
    cout << int64_t(w * 1e6 + (l * 1e6) / qpc_per) << endl;
}

二、我太蠢了，那個計算是爲了取餘數。若是qpc、qpc_per分別是111和10，那麼這個leftover算式至關於111 - (111 / 10 * 10)，獲得的是餘數1，而後用整除後的整數、餘數分別進行換算後相加。

　　總之，最後仍是利用了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，獲得總的硬件時間戳。

 

　　完事了。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程