蜗窝科技

@linuxer：首先多谢您答复！ 1，如果我没有注册signal handler ，只是用sigwait来等待信号的发生，是不是意味着 sigwait 返回后，信号就不阻塞了。 2、信号只提交给正在运行的进程，而信号要得到处理，进程必须要在运行，是不是意味着，不可能出现信号重复挂入队列的情况，也就不存在信号丢失。

@丈二和尚：如果是搞驱动的，可以考虑加入QQ群，里面有很多驱动高手，气氛也很热烈。 如果对内核感兴趣，愿意沉浸在“枯燥”的内核代码中，可以考虑加入微信群。如果觉得自己的确适合微信群，可以搜索Linuxer-at-wowo（这是我的微信号）申请加群。除了这个方法，也可以通过QQ群中的linuxer用户申请加入微信群。

@zhangyx：timer_getoverrun函数返回0，表示该POSIX interval timer没有overrun，大于0表示产生了overrun。例如一个POSIX timer每10ms触发一次，如果在10ms到期后发送了信号并递交到进程，那么说明没有overrun。如果在10ms到期后发送了信号，但是，由于种种原因，该信号在30ms后才递交到进程（即执行signal handler），那么你可以通过timer_getoverrun函数获取该POSIX timer的overrun的次数为2。 Siginfo中的si_overrun表示该信号的overrun次数 timer_getoverrun函数返回是POSIX timer的overrun次数 这两个overrun是不一样的。Siginfo中的si_overrun统计的是整个信号生命周期的overrun次数，包括signal generation到signal delivery。你在send_sigqueue函数中看到info.si_overrun++那是因为信号重复挂入signal pending list而造成的overrun。 timer_getoverrun函数返回是timer视角下的overrun，即interval timer已经触发，按理说应该及时rearm才能产生固定时间间隔的timer事件。对于POSIX timer，触发后发送信号，当完成signal delivery才会rearm timer。然而，信号可能pending很久，例如： 1、 信号只会被递交给正在运行的进程，如果进程阻塞，那么信号不会被递交。 2、 信号可能被阻塞 3、 响应信号（执行signal handler）的时候，往往会block该类型的signal 正因为如此，一个10ms的POSIX interval timer，在触发后会立刻产生信号，然而这个信号可能在30ms递交到进程（signal delivery），在这时候rearm timer已经完了，中间overrun了2次。 因此，timer_getoverrun函数返回非0值并不表示信号丢失，只是表示signal generation到signal delivery的时间太长，超过了POSIX timer的interval time。

@zhangyx：static void schedule_next_timer(struct k_itimer *timr) { struct hrtimer *timer = &timr->it.real.timer; if (timr->it.real.interval.tv64 == 0) return; ******************* timr->it_overrun += (unsigned int) hrtimer_forward(timer, timer->base->get_time(), timr->it.real.interval); timr->it_overrun_last = timr->it_overrun; ******************* timr->it_overrun = -1; ++timr->it_requeue_pending; hrtimer_restart(timer); } 也请跟踪一下上面的函数，实际上调用timer_getoverrun获取的是timr->it_overrun_last的值。

@zhangyx：static enum hrtimer_restart posix_timer_fn(struct hrtimer *timer) { if (posix_timer_event(timr, si_private)) { ********************** timr->it_overrun += (unsigned int) hrtimer_forward(timer, now, timr->it.real.interval); ****************** ret = HRTIMER_RESTART; ++timr->it_requeue_pending; } } unlock_timer(timr, flags); return ret; } 你试着跟踪一下上面的timr->it_overrun的值

看了文章很受启发，许多调试驱动时不谋而合。文章有些细节理解不透彻，想加Linuxer-at-wowo入群交流讨论，却加不了为什么？

这里第二种直接操作文件数据的方式已经绕过文件系统了，也就不存在你说的第二次打开等问题；再者，如果一个文件正在读写，对于数据的一致性，这个应该由应用来维护了

1、使用timer_create (CLOCK_MONOTONIC,.)创建10ms定时器，信号通知的方式触发通知 2、应用里通过sigwait来等待信号的到来，期间调用timer_getoverrun来获取overrun 3、现象是发现有overrun，但是看内核的send_sigqueue函数加打印如下 ret = 0; 7 if (unlikely(!list_empty(&q->list))) { 6 /* 5 * If an SI_TIMER entry is already queue just increment 4 * the overrun count. 3 */ 2 BUG_ON(q->info.si_code != SI_TIMER); 1 BUG_ON(1); printk(KERN_ERR "%s overrun\n", __func__); 1 q->info.si_overrun++; 2 goto out; 3 } 发现没有触发BUG_ON ，也没有打印 ，这里的overrun 跟timer_getoverrun的返回的overrun 不是一个含义吗？ timer_getoverrun 返回非0值，是不是表示有定时器到期信号丢失了？ 内核是uclinux ,内核版本2.6.33 cpu是cortex-m3 期待大神的解答，谢谢！

@lcm：文章写的就是针对linux4.13代码。针对UP系统，spin_lock只需要preempt_disable即可。SMP系统除了preempt_disable之外，还需要申请锁。

大神，看过你以前专门写spinlock文章。最新的内核的spin_lock机制有改变吗？非SMP原来的机制都是1.如果临界区只是在进程里，那么就是spin_lock,即关闭cpu抢占。2.如果是中断中含有临界区，就需要关中断。现在的机制看是加入了排队，取号步骤，如果取不到号让cpu进入低功耗自旋模式。现在这种机制是不是只是针对SMP的呢？