回复 4# Dsheng
谢谢回复！CPU处理这个线程的时间不会超过4mS，具体操作可精简。线程使用的是sched_FIFO。TICK值更改应该要慎重吧？我也认为，Linux对于处理mS级的实时不应该这么烂。那么，你认为问题的关键是在哪里？
回复 9# mordorwww
单个线程运行都是没有问题的，不会出现丢失现象，但是，如果添加了线程调度，或进程调度，就会出现事件丢失的现象。这个，我是利用input子系统来从内核给用户传事件的，读取事件采用的是阻塞的read。
谢谢！
回复 8# duanius
谢谢回复！
曾尝试过剥离用户层工作，想把实时性的搬移到内核来做，但是上层的业务底层根本无法实现。所以只能啃这块骨头了！
谢谢！
哪个kernel？ hrtimer 开了吗？
应该是进程调度的问题
是啊，你这内核版本是多少？
一个线程能及时调度，多线程后，处理事件的线程就不能得到及时响应？
这多个线程的优先级怎么设置的？
回复 14# Dsheng
内核版本是2.6.32
单个线程是能够及时响应的，如果添加另外的线程，响应事件的这个线程就会出现事件丢失现象。如果创建的是普通线程create_normal_pthread，就不会丢失。但是，要求又不能是普通线程，必须是实时线程，并有自己的优先级表。
create_pthread(&atid, SCHED_FIFO, 30,(start_r)FUNC1)//线程1用来响应中断事件
create_pthread(&btid, SCHED_FIFO, 15,(start_r)FUNC2)//线程2仅是执行一些加减运算
其中线程1中：
fd = open("/dev/input/event4", O_RDONLY); //event4为注册的input事件
...
while（1）
{
...
read(fd,&buf,sizeof(struct input_event));
code = buf.code;
switch(code)//判断输入事件是否是中断事件
case KEY_F1://假设KEY_F1就是输入的中断事件
test = test^1;
ioctl(fd_test,test);//调用测试GPIO驱动响应（fd_test只是为了用方便测量响应是否满足要求，当有中断事件发生时，相应GPIO状态翻转，方便用示波器测量）
...
}
丢失事件的现象貌似是有规律的，基本上正常响应两百多个中断后就会丢失10个左右的中断，然后又回复正常，依次循环。
谢谢！
回复 13# blake326
谢谢！
内核版本2.6.32
给14楼回复的比较详细，还望能看一下。
我也认为是调度产生的问题，至于hrtimer，这个倒真没有用到，我的操作如下：
驱动层注册了GPIO的中断，用来接收外部4mS的中断信号。在中断回调函数里input_event上报事件，用户层阻塞read这个事件。结构较为简单。
不知道hrtimer对这种应用有什么益处，还望指出错误并普及一下知识。
谢谢！
我也没想明白，等待高手啊。
对了，你系统里面有没有实时优先级大于30的实时线程啊
回复 16# 21dinglei
你有没有做磁盘io。可能睡眠了？
回复 17# Dsheng
呵呵，非常感谢了！
优先级好像不是关键问题，我层将实时优先级设到最高，效果也是一样的。
应该还是和调度有关系。
因为，系统粒度HZ调到1000之后，现象是有好转的，但是未能根除。