前言

關于優化的話題永遠不過時，沒期限。
評價一個系統的好壞，并不僅僅是它有什么功能，能做到什么。在多大程度上，使用更少的資源，以更快的速度完成相同的工作，這是不可或缺的一個考察項。

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 ，歡迎大家測試
審核編輯：湯梓紅