剛接觸RTOS的時候，不管是ucos還是freertos，都有一個疑問，就是信號量和全局變量比有什么優勢。很多資料上講解是資源的合理分配，后來對源代碼進行了分析，也知道了消息隊列和信號量的整個使用過程。但是還是沒有真正領會其中的意義。最近在做一個電機運動的項目，在電機運動的時候需要用超聲波模塊進行到位判定，超聲波模塊發送數據的頻率是10hz。具體實現的方法是電機運動的時候，打開串口，開始接收超聲波數據。不運動的時候，關閉串口。調試的時候發現一個問題，電機強制停止時的位置靠超聲波擋位的距離不一致。調試判斷是沒有第一時間停止，因為是伺服電機，不存在慣性，所以就推斷是沒有在接收到串口信息之后第一時間判定。簡單來說就是在電機剛進入擋位極限距離時，串口處於關閉狀態（線程保護），處理完數據再次打開串口的時候，電機已經又運動了100ms的時間，如果電機速度夠快，那么就會撞上擋位。
這時候就想起了信號量，看它是怎么實現這個過程的。串口中斷接收完成，釋放信號量。任務中設置阻塞時間等待信號量，阻塞時間的時候CPU處理其它任務，一旦串口信號量釋放成功，那么任務會在第一時間獲取信號量，前提是任務的優先級足夠高。解決了這個問題。此時，應該算是真正理解了信號量（其實隊列也一樣），它做到了全局變量做不到的事情。這是中斷和任務之間的通信，如果換做任務和任務之間，應該也是差不多的。
當然，我相信，如果加入足夠的代碼，也可以用全局變量實現信號量的功能，但是如果這樣，那豈不是白白浪費了前輩們的心血。前人在大量實踐經驗基礎上創造的實現機制，如果暴殄天物，那就實在是罪過罪過。唉！到現在才理解，確實感覺好丟人。面壁思過中。。。
總結：1.要多思考，要不是一直思考這個問題，那么用操作系統的時候一律信號量和消息隊列，那我也不會理解。
2.多實踐，沒有大量的實踐，就無法理解（理解和知道我覺得不是一個意思）一個知識點，當然天賦異稟的除外。
3.勇於嘗試，雖然嘗試會浪費很多時間，也會帶來風險，但是不嘗試，一直呆在舒適區，那就永遠無法進步。