有些是基于alarm实现的，所以不能和alarm同时使用 usleep libc库函数 微秒 - - POSIX.1-2001已将usleep标注为废弃，POSIX.1-2008已删除usleep，应当使用nanosleep...替代usleep nanosleep 系统调用 纳秒 是 不确定 即使被信号中断，也可实现实际睡眠时长不小于参数指定时长 clock_nanosleep 系统调用 纳秒 是 不确定 区别于nanosleep...是 是 即使被信号中断，也可实现实际睡眠时长不小于参数指定时长 pselect 系统调用 纳秒 是 是 如被信号中断，则实际睡眠时长会小于参数指定的时长 C/C++常用封装： 1) 基于nanosleep...(&ts, &ts)) && (EINTR == errno)); } 2) 基于nanosleep的微秒级封装 #include void microsleep(uint32_t microseconds...) { struct timespec ts = { microseconds / 1000000, (microseconds % 1000000) * 1000 }; while ((-1 == nanosleep
有些是基于alarm实现的，所以不能和alarm同时使用 usleep libc库函数 微秒 - - POSIX.1-2001已将usleep标注为废弃，POSIX.1-2008已删除usleep，应当使用nanosleep...替代usleep nanosleep 系统调用 纳秒 是 不确定 即使被信号中断，也可实现实际睡眠时长不小于参数指定时长 clock_nanosleep 系统调用 纳秒 是 不确定 区别于nanosleep...系统调用 微秒 是 是 即使被信号中断，也可实现实际睡眠时长不小于参数指定时长 pselect 系统调用 纳秒 是 是 如被信号中断，则实际睡眠时长会小于参数指定的时长 C/C++常用封装： 1) 基于nanosleep...ts = { milliseconds / 1000, (milliseconds % 1000) * 1000000 }; while ((-1 == nanosleep...{ microseconds / 1000000, (microseconds % 1000000) * 1000 }; while ((-1 == nanosleep
()-->sys_nanosleep()--> hrtimer_nanosleep()--> do_nanosleep()-->hrtimer_start()--> enqueue_hrtimer()...，它能提供纳秒级的延时精度，该用户空间函数对应的内核实现是sys_nanosleep，它的工作交由高精度定时器系统的hrtimer_nanosleep函数实现，最终的大部分工作则由do_nanosleep...hrtimer_nanosleep函数首先在堆栈中创建一个高精度定时器，设置它的到期时间，然后通过do_nanosleep完成最终的延时工作，当前进程在挂起相应的延时时间后，退出do_nanosleep...不过do_nanosleep可能在没有达到所需延时数量时由于其它原因退出，如果出现这种情况，hrtimer_nanosleep的最后部分把剩余的延时时间记入进程的restart_block中，并返回ERESTART_RESTARTBLOCK...; restart->nanosleep.index= t.timer.base->index; restart->nanosleep.rmtp
On Linux, sleep() is implemented via nanosleep(2)....See the nanosleep(2) man page for a discussion of the clock used....即sleep函数是由操作系统的[nanosleep](http://www.man7.org/linux/man-pages/man2/nanosleep.2.html)函数实现的。...asmlinkage long sys_nanosleep(struct timespec __user *rqtp, struct timespec __user *rmtp) { struct
首先我们通过strace工具来看下其调用的系统调用： $ strace sleep 1 ... close(3) = 0 clock_nanosleep...可以发现sleep主要调用clock_nanosleep系统调用来进行睡眠（也就是说用户态任务睡眠需要调用系统调用陷入内核）。...下面我们来研究下clock_nanosleep的实现（这里集中到睡眠的实现，先忽略掉定时器等诸多的技术细节）： kernel/time/posix-timers.c SYSCALL_DEFINE4(clock_nanosleep...//设置超时时要唤醒的任务 ->do_nanosleep //睡眠操作 可以看到，睡眠函数最终调用到hrtimer_nanosleep，它调用了两个主要函数...：__hrtimer_init_sleeper和do_nanosleep，前者主要设置高精度定时器，后者就是真正的睡眠，主要来看下 do_nanosleep： kernel/time/hrtimer.c
VxWorks里常用的定时/延时机制 taskDelay() sleep()/nanosleep() WatchDog Auxiliary Clock Timestamp taskDelay() 详情见...与taskDelay()的不同是 参数是时间 rmtp不为NULL时 – 用于存储sleep()/nanosleep()因为signal提前返回而剩余的时长 定时为0时(secs=0;rqtp->tv_sec...可以看到，sleep 1秒的话，结果是1秒加1个tick，这样就防止了taskDelay()的那个小于1个tick的误差 nanosleep()也是这样操作的: ?...当系统时钟每个tick是1毫秒时，nanosleep()1个纳秒的话，其实是：向上取整为1毫秒(基数是tick的1毫秒)再加1个tick(1毫秒)，即2毫秒。...，但与taskDelay() / sleep() /nanosleep()的区别是：WatchDog定时后的操作是以中断形式执行的，不会受到其它高优先级任务的干扰 Auxiliary Clock 详情见
本文备注/经验分享： 本章节主要涉及两点, 一个是新引入的nanosleep, 另外一个则是一个锁的优化版本的实现.从以前的章节中, 大家都知道, 只要NV开始引入的东西, 那么一般都会在后期发挥重要用途...但是没完, NV在括号里面引入了__nanosleep(), 很好的提高了该锁的性能(还记得刚才说的NV春天发布的推介么)，这里实际上存在一个忙等和避让的概念....__nanosleep目前被编译为单独的一条指令(nanosleep指令, 同名) 从之前我们曾经说过的7.0+开始放宽SIMT的限制了(还记得我们之前说过SIMT带来的弊端和代价么?...，到今天__nanosleep的提供.从本质上来说, 7.0+的GPU越来越靠拢CPU的核心的执行风格了....(例如某种程度上不再绑定32个线程在一起, 而像CPU那样能自由执行) 所以今天引入了__nanosleep()来支援一些原本CPU上常用的算法也很正常了.
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, 0x7fff52691980) = 0 clock_nanosleep(CLOCK_REALTIME..., 0, {tv_sec=0, tv_nsec=0}, 0x7fff52691980) = 0 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec...0 clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, 0x7fff52691980) = 0 exit_group(0) 这下好了！...sleep(0) 并没有被优化掉，它还是去调用了 clock_nanosleep 这个系统调用 。...bpftrace -e 'tracepoint:syscalls:sys_enter_nanosleep{printf("%s is sleeping.
clock_settime(clockid_t ,struct timespec*); 休眠time中指定的时间，如果遇到信号中断而提前返回，则由left_time返回剩余的时间： long clock_nanosleep...二、 延迟函数 主要的延迟函数有：sleep(), usleep(), nanosleep(), select(), pselect(). 1 unsigned int sleep(unsigned int...seconds); 2 void usleep(unsigned long usec); 3 int nanosleep(const struct timespec *req, struct timespec...仅通过函数原型中时间参数类型，可以猜测sleep可以精确到秒级，usleep/select可以精确到微妙级，nanosleep和pselect可 以精确到纳秒级。...而实际实现中，linux上的nanosleep和alarm相同，都是基于内核时钟机制实现，受linux内核时钟实现的影响，并不能达到纳秒级的精 度，man nanosleep也可以看到这个说明，man里给出的精度是
可以发现sleep主要调用clock_nanosleep系统调用来进行睡眠（也就是说用户态任务睡眠需要调用系统调用陷入内核）。...下面我们来研究下clock_nanosleep的实现（这里集中到睡眠的实现，先忽略掉定时器等诸多的技术细节）： kernel/time/posix-timers.c SYSCALL_DEFINE4(clock_nanosleep...//设置超时时要唤醒的任务 ->do_nanosleep //睡眠操作 可以看到，睡眠函数最终调用到hrtimer_nanosleep，它调用了两个主要函数...：__hrtimer_init_sleeper和do_nanosleep，前者主要设置高精度定时器，后者就是真正的睡眠，主要来看下 do_nanosleep： kernel/time/hrtimer.c...do_nanosleep -> do { set_current_state(TASK_INTERRUPTIBLE); //设置可中断的睡眠状态
三、堆栈与源码分析 综合收集的信息，对连接状态、线程状态和堆栈信息进行关联分析，发现被堵塞的 29 个连接中，有 13 个都被卡在函数 nanosleep 中，比较奇怪。...其堆栈关键信息如下： #0 in nanosleep from /lib64/libpthread.so.0 #1 in srv_conc_enter_innodb #2 in ha_innobase...更关键的，看到了 srv_conc_enter_innodb 函数，并由他调用了 nanosleep，执行了类似“睡眠” 的操作。为此，结合对应版本的源码进行分析。...调用 nanosleep 进行指定时间的 sleep e. 设置事务状态为 “” f....= 0、事务没有 ticket、进入 innodb 的事务大于 innodb_thread_concurrency , 执行逻辑： 根据堆栈信息，受影响的会话都被堵塞在 nanosleep 函数；同时
: do_nanosleep <-hrtimer_nanosleep cron-568 [002] .... 45978.504262: __x64_sys_clock_nanosleep <...-do_syscall_64 cron-568 [002] .... 45978.504264: common_nsleep <-__x64_sys_clock_nanosleep cron...: do_nanosleep <-hrtimer_nanosleep sleep-9448 [001] .... 45978.885085: __x64_sys_clock_nanosleep <...-do_syscall_64 sleep-9448 [001] .... 45978.885087: common_nsleep <-__x64_sys_clock_nanosleep sleep...-9448 [001] .... 45978.885087: hrtimer_nanosleep <-common_nsleep # echo nop > current_tracer # echo
() Thread 5 (Thread 1105209696 (LWP 4554)): #0 0x000000302b80baa5 in __nanosleep_nocancel () #1 0x000000000079e758...() Thread 4 (Thread 1115699552 (LWP 4555)): #0 0x000000302b80baa5 in __nanosleep_nocancel () #1 0x0000000000482b0e...() Thread 3 (Thread 1126189408 (LWP 4556)): #0 0x000000302af8f1a5 in __nanosleep_nocancel () from /lib64...() Thread 2 (Thread 1136679264 (LWP 4557)): #0 0x000000302af8f1a5 in __nanosleep_nocancel () from /lib64...() Thread 1 (Thread 182894129792 (LWP 4551)): #0 0x000000302af8f1a5 in __nanosleep_nocancel () from
Nanosleep Nanosleep()系统调用耗时比较。 调用nanosleep()来睡眠0 ns或1 ns似乎也是一个非常便宜的系统调用，甚至是一个空操作。...由于nanosleep()创建了一个定时器，它也会受到这个机制的影响。 因此，其他的nanosleep案例设置了一个最小的定时器松弛值为1ns，这就减少了运行时间，正如预期的那样。...事实证明，无条件地调用nanosleep()会产生一个（自愿的）上下文切换。即使是在孤立的内核上，调度器也会愉快地切换到交换器的内核线程。
一个发生在usleep()调用的hrtimer_nanosleep -> do_nanosleep系统调用；一个发生在printf()的时候，进入sys_write系统调用后，tty_write的n_tty_write...从图上也可以看到，off-cpu的2个主要原因一个是nanosleep，一个是write系统调用进入后n_tty_write里面要拿mutex。
三、堆栈与源码分析综合收集的信息，对连接状态、线程状态和堆栈信息进行关联分析，发现被堵塞的 29 个连接中，有 13 个都被卡在函数 nanosleep 中，比较奇怪。...其堆栈关键信息如下：#0 in nanosleep from /lib64/libpthread.so.0#1 in srv_conc_enter_innodb#2 in ha_innobase:...更关键的，看到了 srv_conc_enter_innodb 函数，并由他调用了 nanosleep，执行了类似“睡眠” 的操作。为此，结合对应版本的源码进行分析。...调用 nanosleep 进行指定时间的 sleep e. 设置事务状态为 “” f....= 0、事务没有 ticket、进入 innodb 的事务大于 innodb_thread_concurrency , 执行逻辑: 图片根据堆栈信息，收影响的会话都被堵塞在 nanosleep 函数；同时
| | | --2.78%--sys_nanosleep...| | --2.35%--hrtimer_nanosleep...| | --2.17%--do_nanosleep...| | | |--0.93%--__libc_nanosleep
总结下来我大致进行了如下的尝试： 1、sleep方案的确定 尝试过 usleep、nanosleep、clock_nanosleep、cond_timedwait、select 等，最终确定用 clock_nanosleep...而用 clock_nanosleep 的好处就是一方面它可以选择时钟源，其次就是它支持绝对时间唤醒，这样我在每次 do_work 之前都设置一下 clock_nanosleep 下一次唤醒时的绝对时间，...那么 clock_nanosleep 实际执行的时间其实就会减去 do_work 的开销，相当于是闹钟的概念。
() from /usr/lib64/libc.so.6 2 Thread 0x7ffff6f56700 (LWP 1195) "main" 0x00007ffff701bfad in nanosleep...() from /usr/lib64/libc.so.6 3 Thread 0x7ffff6755700 (LWP 1196) "main" 0x00007ffff701bfad in nanosleep...(gdb) thread 1 [Switching to thread 1 (Thread 0x7ffff7feb740 (LWP 1191))] #0 0x00007ffff701bfad in nanosleep...(gdb) thread 1 [Switching to thread 1 (Thread 0x7ffff7feb740 (LWP 1191))] #0 0x00007ffff701bfad in nanosleep...lib64/libc.so.6 (gdb) set scheduler-locking step (gdb) next Single stepping until exit from function nanosleep
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x00007f578fb7a9d0 in __GI___nanosleep.../sysdeps/unix/sysv/linux/nanosleep.c:28 28 ...../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory....Target Id Frame * 1 Thread 0x7f57902be740 (LWP 17641) "test" 0x00007f578fb7a9d0 in __GI___nanosleep.../sysdeps/unix/sysv/linux/nanosleep.c:28 2 Thread 0x7f578fa95700 (LWP 17642) "test" __lll_lock_wait
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
