小编Lnx*_*gr3的帖子

受到最后一个闰秒的启发,我一直在探索使用POSIX调用的计时(特别是间隔计时器).

POSIX提供了几种设置计时器的方法,但它们都有问题:

• sleep并且nanosleep这些在被信号中断后重新启动很烦人,并引入了时钟偏差.您可以通过一些额外的工作来避免一些但不是全部的这种偏差,但这些功能使用实时时钟,所以这并非没有陷阱.
• setitimer或者更现代的timer_settime这些被设计为间隔计时器,但它们是每个进程,如果您需要多个活动计时器,这是一个问题.它们也不能同步使用,但这不是什么大问题.
• clock_gettime并且clock_nanosleep在使用时看起来像是正确的答案CLOCK_MONOTONIC.clock_nanosleep支持绝对超时,因此您可以只是睡眠,增加超时,然后重复.在中断之后也很容易重启.不幸的是,这些功能可能也是特定于Linux的:在Mac OS X或FreeBSD上不支持它们.
• pthread_cond_timedwait可以在Mac上使用,可以gettimeofday作为一个kludgy解决方案,但在Mac上它只能与实时时钟一起使用,因此当系统时钟设置或闰秒发生时,它会受到不当行为的影响.

我缺少一个API吗？是否有一种合理的可移植方式在类UNIX系统上创建性能良好的间隔定时器,或者这总结了今天的状态？

通过良好的行为和合理的便携性,我的意思是:

• 不容易出现时钟偏差(当然,减去系统时钟自身的偏差)
• 适应正在设置的系统时钟或发生闰秒
• 能够在同一个过程中支持多个计时器
• 至少可在Linux,Mac OS X和FreeBSD上使用

关于闰秒的注释(响应R ..的回答):

POSIX天的长度恰好是86,400秒,但现实世界的日子很少会更长或更短.系统如何解决这种差异是由实现定义的,但闰秒通常与前一秒共享相同的UNIX时间戳.另请参见:闰秒以及如何处理它们.

Linux内核闰第二个错误是在将时钟设置为秒后无法进行内务处理的结果:https://lkml.org/lkml/2012/7/1/203.即使没有那个错误,时钟也会向后跳一秒钟.

传统观念认为,功能内联并不总是有益,甚至可能会损害性能:

• Linux内核样式指南警告不要过度内联
• 谷歌还建议程序员小心内联
• 在C++ FAQ精简版说更多的相同

我理解为什么内联应该有所帮助 - 它通过在调用者中包含被调用的函数来消除函数调用开销.

我也理解为什么人们声称它会损害性能 - 内联函数在某些情况下会增加代码大小,这最终会增加缓存未命中甚至触发额外的页面错误.这一切都有道理.

不过,我遇到了麻烦,找到了内联实际会伤害性能的具体例子.当然,如果一个问题足以值得警告,那么某个地方的人必定会遇到一个内联是一个问题的例子.所以,我问......

什么是一个好的,具体的代码示例,其中性能实际上受到函数内联的影响？

为了我自己的病态,我正在编写一个用于Linux的x86_64程序集中的小程序.但是,在一个比较立即操作数和寄存器的指令中,我遇到了一个对我来说完全没有意义的段错误.是什么赋予了？

这是导致崩溃的代码:

_start:
    sub $8, %rsp
    mov %rsp, %rbx
    lea le_string(%rip), %rsi
    mov %rsi, %rdi
    add $8, %rdi
    mov $26, %cl
    mov (%rsi), %al
    cmp 'A', %al /* This line segfaults */
    /* snip code that never runs */

le_string:
.ascii "YrFgevat"

我正在组装gcc -nostdlib,它正在调用GNU汇编程序.

崩溃后倾倒寄存器显示:

• %rsi 包含指向字符串的预期指针
• %al 包含字符串中预期的第一个字符
• %rip 指向不接触内存的指令

请忽略缺少正常的调用约定 - 除了系统调用接口之外我没有调用任何东西,并且在它甚至到达那么远之前崩溃了!