3.uCOS II和大家所熟知的Linux等分時操作系統不同，它不支持時間片輪轉法。uCOS II是一個基于優先級的實時操作系統，每個任務的優先級必須不同，分析它的源碼會發現，uCOS II把任務的優先級當做任務的標識來使用，如果優先級相同，任務將無法區分。進入就緒態的優先級較高的任務首先得到CPU的使用權，只有等它交出CPU的使用權后，其他任務才可以被執行。所以它只能說是多任務，不能說是多進程，至少不是我們所熟悉的那種多進程。顯而易見，如果只考慮實時性，它當然比分時系統好，它可以保證重要任務總是優先占有CPU。但是在系統中，重要任務畢竟是有限的，這就使得劃分其他任務的優先權變成了一個讓人費神的問題。另外，有些任務交替執行反而對用戶更有利。例如，用單片機控制兩小塊顯示屏時，無論是編程者還是使用者肯定希望它們同時工作，而不是顯示完一塊顯示屏的信息以后再顯示另一塊顯示屏的信息。這時候，要是uCOS II即支持優先級法又支持時間片輪轉法就更合適了。

  4.uCOS II對共享資源提供了保護機制。正如上文所提到的，uCOS II是一個支持多任務的操作系統。一個完整的程序可以劃分成幾個任務，不同的任務執行不同的功能。這樣，一個任務就相當于模塊化設計中的一個子模塊。在任務中添加代碼時，只要不是共享資源就不必擔心互相之間有影響。而對于共享資源（比如串口），uCOS II也提供了很好的解決辦法。一般情況下使用的是信號量的方法。簡單地說，先創建一個信號量并對它進行初始化。當一個任務需要使用一個共享資源時，它必須先申請得到這個信號量，而一旦得到了此信號量，那就只有等使用完了該資源，信號量才會被釋放。在這個過程中即使有優先權更高的任務進入了就緒態，因為無法得到此信號量，也不能使用該資源。這個特點的好處顯而易見，例如當顯示屏正在顯示信息的時候，外部產生了一個中斷，而在中斷服務程序中需要顯示屏顯示其他信息。這樣，退出中斷服務程序后，原有的信息就可能被破壞了。而在μC/OS-II中采用信號量的方法時，只有顯示屏把原有信息顯示完畢后才可以顯示新信息，從而可以避免這個現象。不過，采用這種方法是以犧牲系統的實時性為代價的。如果顯示原有信息需要耗費大量時間，系統只好等待。從結果上看，等于延長了中斷響應時間，這對于未顯示信息是報警信息的情況，無疑是致命的。發生這種情況，在μC/OS-II中稱為優先級反轉，就是高優先級任務必須等待低優先級任務的完成。在上述情況下，在兩個任務之間發生優先級反轉是無法避免的。所以在使用uCOS II時，必須對所開發的系統了解清楚，才能決定對于某種共享資源是否使用信號量。

[1]  [2]  [3]  [4]