rt-thread 优化系列（一） 之 过多关中断

前言

关于优化的话题永远不过时，没期限。
评价一个系统的好坏，并不仅仅是它有什么功能，能做到什么。在多大程度上，使用更少的资源，以更快的速度完成相同的工作，这是不可或缺的一个考察项。

rt-thread 值得优化的地方还很多。作为本系统优化系列开篇，先从关中断聊起。

提出问题

论坛上曾经有很多人反应丢数据啊，终端输入命令太快出现什么什么异常啦。
起初看到这些人反映的问题，第一反应是他们用法错误，代码有隐藏 bug 导致程序运行不正常。但是，当多人在不同的应用场景开始反映相似问题的时候，我也心虚了。我开始尝试着引导他们去做一些优化处理，试试能不能减轻问题的严重性。有时候可能只需要调整两句代码，但是结果是明显的，前后效果是有差别的。虽然他们的应用场景不一样，但是多数是要和中断打交道的，经过多方排查以及怀疑，最终我把目标转移到了关中断操作上。

我把这种现象叫过关中断，过度使用关中断进而引起副作用。

一个小例子

以 rt_thread_resume 函数为例，某次提交更改之前是这样的

   rt_timer_stop(&thread->thread_timer);
   /* enable interrupt */
   rt_hw_interrupt_enable(temp);

   /* insert to schedule ready list */
   rt_schedule_insert_thread(thread);

更改之后

   rt_timer_stop(&thread->thread_timer);
   /* insert to schedule ready list */
   rt_schedule_insert_thread(thread);

   /* enable interrupt */
   rt_hw_interrupt_enable(temp);

可以查到， rt_schedule_insert_thread 函数有它自己内部的关中断处理，这里调整这两句的操作是不是没有必要了？
上面代码执行的 rt_hw_interrupt_disable rt_hw_interrupt_enable 函数对数是一样的，不同的是更改前分成两部分，中间可以有开中断的机会，但是更改后这个机会没了，调整后最长关中断时间延长了。
如果这里的调整是必要的，也可以查到所有调用 rt_schedule_insert_thread 函数的其它地方都是关中断的。那么 rt_schedule_insert_thread 自己内部的关中断操作是不是就多余了？

上面的 rt_timer_stop 执行位置也有延长关中断时间的副作用。

其它可疑过关中断

比如 rt_thread_suspend 函数，开头关中断是这样的。

   /* disable interrupt */
   temp = rt_hw_interrupt_disable();
   if (stat == RT_THREAD_RUNNING)
   {
       /* not suspend running status thread on other core */
       RT_ASSERT(thread == rt_thread_self());
   }

其中，stat 的赋值没放到中断里，后面这个简短的判断就必须放进关中断？

其它的还有 rt_ipc_list_resume_all stm32_pin_irq_enable ...

影响

论坛里已经有多次反应的问题和中断有关，引起的后果不是丢失数据就是线程挂起和内核消息脱钩。如下是部分问题链接。
https://club.rt-thread.org/ask/question/432195.html
https://club.rt-thread.org/ask/question/432183.html
https://club.rt-thread.org/ask/question/432083.html
https://club.rt-thread.org/ask/question/432048.html

结尾

接下来本优化系列计划：软定时器，消息机制；还有第三方组件部分，由于组件包太多，不可能把每一个都搞一遍，所以我会挑其中的一两个。敬请期待。

> 本优化系列所有提到的更改已经提交到 gitee ，欢迎大家测试
审核编辑：汤梓红