RTAI的用户空间编程（五）——注意事项

1. 所谓的LXRT实即Linux Real Time module，不存在LXRT scheduler
   所谓的LXRT实即Linux Real Time module，不存在LXRT scheduler。RTAI下只有3种调度器,UP,SMP和MUP。LXRT的存在使得RTAI所有的调度函数都能在Linux进程中直接调用。这样一来，RTAI的实时服务就具备了所谓的“完全对称”——在RTAI域和LINUX域中的使用几乎完全一样。也就是说，用户可以在LINUX和LINUX间，RTAI和LINUX间共用内存，发送消息，调用semaphore或时间相关服务，当然，在RTAI和RTAI之间更不是问题。（源自DIAPM RTAI - Beginner’s Guide，https://www.rtai.org/index.php?module=documents&JAS_DocumentManager_op=downloadFile&JAS_File_id=32）
2. LXRT下的硬实时相对于内核态下而言仍有若干微秒的差别
   LXRT下的hard real time还是与内核态任务的执行有着本质区别的。RTAI通过其RTAI_PROTO为用户态下进程提供调用内核API的捷径，并由RTAI自身的调度器保证了RTAI任务对中断的优先权。处于中断处理链条终端的LINUX因此不能破坏RTAI任务的实时性能。但无论如何,context switch是需要时间的。在RTAI域内用户态和内核态的切换也免不了牺牲一定的时间开销。RTAI相关的文档指出LXRT下的硬实时相对于内核态下而言仍有若干微秒的差别。笔者也在试验中发现，前者实时性能与后者相比相差约有十几微秒，有时甚至更多。对于一些要求苛刻的实时任务而言，LXRT下的时延（或者还有实时误差？）是无法接受的。
3. 在进入和离开LXRT域这两段时间，系统的实时性是无法保证的。
   也就是说，在时间轴上的这两个区间，所有LXRT任务并非处于真正的硬实时状态，期间任何操作都有可能因其不稳定性导致10～20微秒的实时误差（具体数值未做严密测量）。这一点在RTAI自身文档中也有阐述，但因为不引人注意，使得基于RTAI/LXRT的实时控制开发人员非常容易忽略。对这一问题的最简单处理办法就是在调用rt_make_hard_real_time()后随即插入短暂的等待，再进入实时处理阶段。实践中笔者在等待500微秒后得到理想的实时表现。
4. stop_rt_timer是全局变量，如果在进程中某个线程结束时候使用，则会结束全部线程的定时器。
   解决这种情况可以，一，全部用周期，这样既不用去start也不用去stop；二，每个单独启动oneshot定时，然后在最后再结束。