浅析libuv源码-获取精确时间

  在Timer模块中有提到,libuv控制着延迟事件的触发,那么必须想办法精确控制时间。

  如果是JS,获取当前时间可以直接通过Date.now()得到一个时间戳,然后将两段时间戳相减得到时间差。一般情况下当然没有问题,但是这个方法并不保险,因为本地计算机时间可以修改。

  libuv显然不会用这么愚蠢的办法来计算时间,C++内部有更为精妙的方法来处理这个事。

  首先在上一节中,一个简单的事件轮询代码如下:

int main() {
    uv_loop_t *loop = uv_default_loop();
    uv_run(loop, UV_RUN_DEFAULT);
}

  这里的uv_default_loop会生成一个默认的静态对象,负责管理事件轮询,而这个对象有一个属性,则负责记录当前的时间,如下:

  /* The current time according to the event loop. in msecs. */
  uint64_t time; 

  简单讲就是记录当前这一轮事件开始处理的时间,单位为毫秒。

  在初始化之后,就会执行uv_run来开始事件轮询了,因为这节只讲时间,所以省略无关代码,如下:

int uv_run(uv_loop_t *loop, uv_run_mode mode) {
    // ...
    // 查询是否有未处理事件
    r = uv__loop_alive(loop);
    if (!r)
        // 表示处理完一轮事件 更新时间
        uv_update_time(loop);

    // 如果有未处理事件
    while (r != 0 && loop->stop_flag == 0) {
        // 这里也会更新时间
        uv_update_time(loop);
        // ...
    }
}

  可见,每次轮询时都会更新时间,方法就是那个uv_update_time,源码如下:

void uv_update_time(uv_loop_t* loop) {
    // 返回一个时间
    uint64_t new_time = uv__hrtime(1000);
    // 检测数据合法性并赋值
    assert(new_time >= loop->time);
    loop->time = new_time;
}

uint64_t uv__hrtime(double scale) {
    LARGE_INTEGER counter;

    if (hrtime_interval_ == 0) {
        return 0;
    }

    if (!QueryPerformanceCounter(&counter)) {
        return 0;
    }

    return (uint64_t)((double)counter.QuadPart * hrtime_interval_ * scale);
}

  上面的方法通过一些计算,会返回一个类似于时间戳的长整数。

  C++的方法都比较简单,首先看一下hrtime_interval_,从名字可以看出这是一个代表频率的数字,相关的定义和设置代码如下:

/* Interval (in seconds) of the high-resolution clock. */
static double hrtime_interval_ = 0;

/*
 * One-time initialization code for functionality defined in util.c.
 */
void uv__util_init(void) {
    LARGE_INTEGER perf_frequency;

    /* 加锁 不管这个 */
    InitializeCriticalSection(&process_title_lock);

    /* Retrieve high-resolution timer frequency
     * and precompute its reciprocal.
     */
    if (QueryPerformanceFrequency(&perf_frequency)) {
        hrtime_interval_ = 1.0 / perf_frequency.QuadPart;
    }
    else {
        hrtime_interval_ = 0;
    }
}

  该值的初始化为0,然后会通过某个计算尝试重新赋值。

  这里需要介绍一下两个windowsAPI: QueryPerformanceFrequency 与 QueryPerformanceCounter 。

  定义非常简单,字面理解一个是系统性能频率,一个是系统性能计数器,具体讲,第一个会返回当前操作系统每秒钟会统计多少次,第二个返回当前已经统计的次数(类似于时间戳从1970年开始,这个应该也有一个参照物),依赖于硬件支持,如果不支持会返回0。

  可以通过一个简单的案例来理解这两个API,测试代码如下:

int main() {
    LARGE_INTEGER m;
    LARGE_INTEGER n1;
    LARGE_INTEGER n2;
    // 获取每秒钟统计的次数
    QueryPerformanceFrequency(&m);
    for (int i = 0; i < 5; i++) {
        // 获取当前的统计次数
        QueryPerformanceCounter(&n1);
        // zzz...线程等待一秒
        Sleep(1000);
        // 获取一秒后统计次数
        QueryPerformanceCounter(&n2);
        // 计算sleep方法实际时间
        cout << "过去了" << (double)(n2.QuadPart - n1.QuadPart) / (double)m.QuadPart << "秒" << endl;
    }
    return 0;
}

  执行后输出如下:

  可见,系统的1秒钟实际上并不十分精确。

  回到hrtime_interval_的定义:

hrtime_interval_ = 1.0 / perf_frequency.QuadPart;

  很容易知道这里返回的是系统每计数一次所需要的时间。

  然后可以理解uv_hrtime方法具体的返回:

uint64_t uv__hrtime(double scale) {
    LARGE_INTEGER counter;
    // 如果硬件不支持 返回0
    if (hrtime_interval_ == 0) {
        return 0;
    }
    // 获得当前计数
    if (!QueryPerformanceCounter(&counter)) {
        return 0;
    }
    // 返回当前计数所花费的时间 默认为秒scale(1000)转换为毫秒
    return (uint64_t)((double)counter.QuadPart * hrtime_interval_ * scale);
}

  由于 QueryPerformanceFrequency  与 QueryPerformanceCounter  并不依赖于本地时间,所以计算得到的数值可以保证绝对安全。

  不过,这个数字的计算方式,简直跟时间戳一模一样啊。

原文地址:https://www.cnblogs.com/QH-Jimmy/p/10080857.html

时间: 2024-08-02 06:19:36

浅析libuv源码-获取精确时间的相关文章

浅析libuv源码-node事件轮询解析(1)

好久没写东西了,过了一段咸鱼生活,无意中想起了脉脉上面一句话: 始终保持自己的竞争力.所以,继续开写! 一般的JavaScript源码看的已经没啥意思了,我也不会写什么xx入门新手教程,最终决定还是啃原来的硬骨头,从外层libuv => node => v8一步步实现原有的目标吧. libuv核心还是事件轮询,前几天从头到尾看了一遍官网的文档,对此有了一些更深的理解. (虽然现在开发用的mac,但是为了衔接前面的文章,所以代码仍旧以windows系统为基础,反正差别也不大) 首先看一眼官网给的

浅析libuv源码-node事件轮询解析(4)

这篇应该能结,简图如下. 上一篇讲到了uv__work_submit方法,接着写了. void uv__work_submit(uv_loop_t* loop, struct uv__work* w, enum uv__work_kind kind, void (*work)(struct uv__work* w), void (*done)(struct uv__work* w, int status)) { // 上篇主要讲的这里 初始化线程池等 uv_once(&once, init_on

【Linux学习】 写一个简单的Makefile编译源码获取当前系统时间

打算学习一下Linux,这两天先看了一下gcc的简单用法以及makefile的写法,今天是周末,天气闷热超市,早晨突然发现住处的冰箱可以用了,于是先出去吃了点东西,然后去超市买了一坨冰棍,老冰棍居多,5毛钱一根,还有几根1.5的. 嗯 接着说gcc的事 先把源代码贴上来 //gettime.h #ifndef _GET_TIME_H_ #define _GET_TIME_H_ void PrintCurrentTime(); #endif //gettime.c #include <stdio.

Tools:Installing and using the Required Tools for downloading and Building EDK II工具篇:安装/使用EDKII源码获取/

Tools:Installing and using the Required Tools for downloading and Building EDK II工具篇:安装/使用EDKII源码获取/编译工具[2.3] 2015-07   北京海淀区  张俊浩 2. Setting Up EDKII Development Environment(EDKII开发环境的搭建) ->2.1 The General Procedure Of Setting Up EDKII Development E

libuv源码分析前言

Libevent,libev,libuv三者的区别所在? libevent提供了全套解决方案(事件库,非阻塞IO库,http库,DNS客户端),然而libevent使用全局变量,导致非线程安全.它的watcher结构也过大,把I/O.计时器.信号句柄整合在一起.而且(作者认为)libevent的附加组件如http和dns库都实现不好,且有安全问题. libev因libevent而诞生,对libevent做了改进,避免使用全局变量,拆分watcher等.另外libev去掉了外部库(比如http和d

谷歌开源项目Chromium的源码获取与项目构建(Win7+vs10/vs13)

转自:http://blog.csdn.net/kuerjinjin/article/details/23563059 从12年那会儿开始获取源码和构建chromium项目都是按照那时候的官方要求用win7+vs2010,相对来说也比较简单,按照步骤来也很快能编译出来. 1.官网的编译配置介绍:http://www.chromium.org/developers/how-tos/build-instructions-windows 2.编译需要的工具:vs2010/sp1,win8sdk,DXS

阿里架构师浅析ThreadLocal源码——黄金分割数的使用

一. 前提 最近接触到的一个项目要兼容新老系统,最终采用了ThreadLocal(实际上用的是InheritableThreadLocal)用于在子线程获取父线程中共享的变量.问题是解决了,但是后来发现对ThreadLocal的理解不够深入,于是顺便把它的源码阅读理解了一遍.在谈到ThreadLocal之前先买个关子,先谈谈黄金分割数.本文在阅读ThreadLocal源码的时候是使用JDK8(1.8.0_181). 二. 黄金分割数与斐波那契数列 首先复习一下斐波那契数列,下面的推导过程来自某搜

kettle系列-1.kettle源码获取与运行

第一次写博客,心里有点小激动,肯定有很多需要改进的地方,望海涵. kettle算是我相对较为深入研究过的开源软件了,也是我最喜欢的开源软件之一,它可以完成工作中很多体力劳动,在ETL数据抽取方面得到了广泛的使用.我本身对kettle的各个控件使用也不是很熟悉,只会使用最常见的部分控件,就是这样简单的使用也被它的美深深的吸引住了. 好了,进入正题,这里假设你熟悉java开发.git一般使用.kettle一般使用.kettle源码之前托管在kettle官方的svn上,后来迁移到了github上,在g

Nodejs事件引擎libuv源码剖析之:高效线程池(threadpool)的实现

声明:本文为原创博文,转载请注明出处. Nodejs编程是全异步的,这就意味着我们不必每次都阻塞等待该次操作的结果,而事件完成(就绪)时会主动回调通知我们.在网络编程中,一般都是基于Reactor线程模型的变种,无论其怎么演化,其核心组件都包含了Reactor实例(提供事件注册.注销.通知功能).多路复用器(由操作系统提供,比如kqueue.select.epoll等).事件处理器(负责事件的处理)以及事件源(linux中这就是描述符)这四个组件.一般,会单独启动一个线程运行Reactor实例来