• 计时函数
• 定时函数
• 多线程服务端中的选择
• 参考

计时函数

用于获取当前（日期）时间：

• time(2) / time_t （秒）
• ftime(3) / struct timeb （毫秒）
• gettimeofday(2) / struct timeval （微妙）
• clock_gettime(2) / struct timespec （纳秒）

gmtime / localtime / timegm / mktime / strftime / struct tm 是等与当前时间无关的时间格式转换函数。

定时函数

用于让程序等待一段时间或安排计划任务：

• sleep(3)
• alarm(2)
• usleep(3)
• nanosleep(2)
• clock_nanosleep(2)
• getitimer(2) / setitimer(2)
• timer_create(2) / timer_settime(2) / timer_gettime(2) / timer_delete(2)
• timerfd_create(2) / timerfd_gettime(2) / timerfd_settime(2)

多线程服务端中的选择

对于多线程服务端编程：

• 计时，使用gettimeofday(2)来获取当前时间；
• 定时，使用timerfd_*系列函数来处理定时任务。

gettimeofday(2) 原型：

#include <sys/time.h>
int gettimeofday(struct timeval *tv, struct timezone *tz);

计时选gettimeofday(2) 原因：
1）time(2)精度太低，ftime(3)已被废弃；clock_gettime(2)精度最高，但其系统调用开销比gettimeofday(2)大。
2）在x86-64平台上，gettimeofday(2)不是系统调用，而是在用户态实现的，没有上下文切换和陷入内核的开销。
参考：https://lwn.net/Articles/446528/
3）gettimeofday(2)分辨率1us，而且现在的实现确实能达到，满足日常计时需要。

struct timeval {
    time_t      tv_sec;     /* seconds */
    suseconds_t tv_usec;    /* microseconds */
};

可自定义Timestamp类，用int64_t来表示从Unix Epoch到现在的微妙数，范围可达30万年。

定时选timerfd_*的原因：
1）sleep(3) / alarm(3) / usleep(3) 在实现时有可能用了SIGALRM信号，在多线程程序中处理信号相当麻烦，应尽量避免。而且，如果主程序和程序库都用了SIGALRM，就糟糕了。
2）nanosleep（2）和clock_nanosleep(2)线程安全，但在非阻塞网络编程中，不能让线程挂起来等待一段时间，这样程序会失去响应。正确的做法是注册一个时间回调函数。
3）getitimer(2)和timer_create(2)也是用信号来deliver（递达）超时，在多线程程序中也会很麻烦。timer_create(2)可以指定信号的接收方是进程还是线程，是个进步，但信号处理函数（signal handler）能做的事情很受限。
4）timerfd_create(2)把时间变成一个文件描述符，该“文件”在定时器超时的那一刻变得可读，这样就能很方便地融入select(2) / poll(2)框架中，用统一的方式来处理IO事件和超时事件，这也是Reactor模式长处。
5）传统Reactor利用select(2) / poll(2) / epoll(4) 的timeout来实现定时功能，但poll(2)和epoll_wait(2)的定时精度只有毫秒，远低于timerfd_settime(2) 的定时精度。

参考

[1]陈硕. Linux多线程服务端编程[M]. 电子工业出版社, 2013.