◆ 任務，在ucos-ii實時系統中，乙個任務其實就是乙個執行緒，該任務可以認為cpu完全屬於它自己。ucos-ii中的任務擁有自己的堆疊和cpu暫存器，並且賦予一定的優先順序，在ucos-ii中，它可能處於睡眠、就緒、執行、等待、中斷服務狀態之一。具體這5種狀態的定義請看我的另一篇博文《ucos learning notes n.o. 01》。
◆ 基於優先順序的核心有兩種：不可剝奪型和可剝奪型。不可剝奪型核心它要求每個任務互相合作，也稱為合作型核心，每個任務不會被其它任務剝奪去，除非中斷的到來，即便如此，當中斷結束後，還是會回到原來被中斷的程式，而不會切換到具有高優先順序的任務中去，這樣，高優先順序的任務就不能夠及時得到執行，所以它的實時性是比較差的。但是它有乙個很重要的特點，就是它可以使用不可重入函式，因為每個任務必須執行完，才能釋放cpu，這樣它對其它任務呼叫可重入函式沒有影響；同理在大多數情況下它無須使用訊號量來保護資源。[2007-9-19
補記：我們有時候寫前後臺的程式時，通常利用了分時的觀念，即我們在延遲中執行其他**，這從本質上也可以說是借鑑不可剝奪的核心特點來寫的，至少它們有相同之處吧，不過這要球程式對自己的程式執行過程非常清楚，其實這也是正確使用ucos實現它最優實時性的前提，不過這境界有點難咯，我自己也沒有做到，讓我們努力吧！]
對於可剝奪型核心，只要高優先順序任務一就緒，那它就會被執行，而當前正在執行的任務就會被掛起；正因為如此，對於系統的資源就不能像不可剝奪型那樣去使用，而是在使用前必須檢查是否可以使用，即互斥機制來保護臨界資源，如果不用的話，那麼如果低優先順序在使用臨界資源時，突然被高優先順序把cpu給搶過去了，那麼低優先順序的臨界資源就可能會被告優先順序任務給破壞掉；可剝奪型的優點是是系統的響應時間得到了優化，且是可知的。
◆ 實時系統中，中斷優先順序反轉這一問題是出現得最多的，這問題的本質其實也不能理解，就是低優先順序的任務占有高優先順序的任務所需要的資源，而使高優先順序不得不等低優先順序把資源釋放才能執行。
◆ 任務控制塊os_tcb，它是乙個有結構體組成的，每當乙個任務被建立時，它就會被建立，並且和系統中的任務組成乙個雙向鍊錶，它的第乙個結構體成員是堆疊棧頂指標，這樣做的好處避免在移植過程中出現不必要的偏移位址計算過程，節省了cpu的時間，由於它是乙個雙向鍊錶，自然會有前向指標【指向前面乙個任務控制塊】和後向指標【指向後面乙個任務控制塊指標，最後乙個任務塊指標指向空指標】，還包含有與該任務優先順序以及與優先順序相關的資料成員和與該任務有關的事件、郵箱、佇列等，其它的成員我暫時用不著，先pk掉，以後用時再看。在這個結構體中，我覺得應該值得時刻注意的是：任務堆疊指標，任務狀態，任務優先順序。
◆ 任務控制塊的初始化，它其實就是從空任務控制塊中取乙個任務控制塊，並對它的成員進行初始化。
◆ 任務的就緒表，我認為這時ucos中的幾個經典部分之一，記得我當時第一次看它時，發現這很奇妙，心中直誇作者的智慧型。我們在建立任務時，系統跟住優先順序來分配控制塊和堆疊，首先系統會對優先順序進行乙個檢查，如果該優先順序沒有被其它任務占有，那麼它就分配給該任務；同時這很明顯會出現乙個問題，怎樣去管理這些優先順序以及怎樣知道優先順序的使用情況就成了該系統自然要解決的問題，該系統的作者很有智慧型，發現了優先順序的數字有這麼乙個功能，系統有64個優先順序，由於我們的位元組是8位的，呵呵，很明顯來個8*8的矩陣，再仔細一看，原來乙個優先順序的位3~5的10進製數可以作為優先順序在哪一組，位0~2的10進製數可以作為在該組中某位為1的位，然後一算，呵呵恰好是優先順序的數，這種思維在ucos中用了好幾次。系統在進行任務切換時，是把cpu分配就緒表中優先順序最高的任務，那怎樣來找呢，因為我們已經知道優先順序的數字有那麼乙個巧妙在裡面，何不好好利用之呢，我們要想知道就緒任務的最高優先順序的值，就要知道優先順序所在的組以及所在列，我們先來找組，因為優先順序的值越小優先順序越高，那麼無論就緒表中的表那幾組為1，就緒任務肯定在最低一位為1所在的列中找，那麼很自然我們可以這樣來見表，依次從0~255開始來設，即優先順序組的值為1時是在第幾組，為253時又在第幾組，這個表一建成，就是乙個1*256的陣列，再仔細看發現找列時也可以跟住這個表來查詢，真是得來全不費功夫。優先順序的低3位和3~5位都知道了，然後在跟住優先順序就緒表的原理反過來就可以計算出就緒表中任務最高優先順序的值拉。
◆ os_enter_critical()和os_exit_critical()也可以用來保護應用程式中的臨界**；然而要特別小心，如果在呼叫一些如ostimedel()之類的功能函式之前關中斷，應用程式將會宕機；原因是任務被掛起一段時間，直到掛起時間到，但由於中斷關掉了，時鐘節拍中斷一直得不到服務，顯然所有的掛起類呼叫都有這樣的問題，所以要特別小心。作為一條普遍適用的規則，呼叫
ucos-ii
功能函式時，中斷總是開著的。
◆ 任務排程，因為ucos總是執行優先順序最高的任務，而cpu的使用權轉移到優先順序最高的任務這一過程是通過任務排程來完成的，具體它的實現步驟在ucos中其實現**是比較簡單的，首先是關中斷，其次檢查其呼叫是否來自中斷或者至少呼叫了一次給任務排程上鎖函式，並且沒有釋放鎖，都將不能執行排程，否則發生死鎖，簡單說明一下，在中斷中，肯定是不能排程的，應該不難理解，如果任務呼叫了上鎖函式，但是又沒有釋放，即沒有釋放資源，那麼很有可能其它任務需要那資源而發生優先順序反轉現象。然後在執行任務的切換。
◆ 任務級的任務切換和中斷級的任務切換，其具體思路清參照我寫得
◆ 給排程器上鎖和開鎖，給排程器上鎖用於禁止任務排程，一般它開鎖成對使用，其在ucos中的實現**很簡單，只是要特別注意的是，上鎖時要先關中斷。
◆ 空閒任務，ucos中至少要有乙個任務，那就是空閒任務，不過其優先順序最低，也就是說當其它任務沒有進入就緒表時，它才執行，因為它總是處於就緒狀態，它只是乙個簡單的計數器計數。在統計任務中要用到它。
◆ 統計任務，它就做一件事，就是計算cpu的利用率，可這過程我個人認為要一定的時間，因為裡面盡是計算，並且牽涉到除法。在ucos啟動時，如果要啟動統計任務，首先要把os_cfg.h中的os_task_stat_en設為1，那麼這個任務就會建立，且一直處於就緒狀態，並且剛開始時，由於空閒任務，肯定會執行的，執行多久，1秒，為什麼是1秒，自己分析下**就會明白啦，計數1秒又有什麼用呢，為以後計算cpu的利用率提供乙個基準值，因為這個值將會一直儲存起來的，儲存在哪，儲存在統計任務的堆疊裡，且不會改變，除非重新啟動cpu；那麼以後空閒任務不一定會有1秒的時間連續執行，空閒任務執行時，沒次被其它任務搶走cpu時，它裡面的計數器就會直接記錄下cpu空閒的時間，怎麼算呢，1s內它的計數值我們是知道的，那麼cpu以後空閒的計數值我們也有記錄，只是這些計算過程由統計任務來完成。
◆ ucos
的初始化，它首先是系統所用的全域性變數比如上鎖次數，中斷次數，任務次數，任務切換次數等等的初始化，然後是就緒列表、任務控制塊、事件控制塊等的建立，其次是空閒任務或和統計任務的建立。
◆ ucos
的啟動，找出就緒列表中的優先順序最高的任務，並啟動任務排程，且永不返回。
UCOS II核心結構
1.1 臨界段可以關中斷來保持獨佔。為什麼可以關中斷來保持獨佔呢？因為能引起排程的有兩個，乙個是呼叫 系統函式，另外乙個是中斷喚醒了乙個事件。而明顯進入臨界段是不會呼叫系統函式的了，因而意外的就是 可能會發生中斷，所以把中斷關掉了，就不會發生排程了。1.2 任務 ucos的任務可以達64個，但是最高...
Linux核心結構
linux核心主要由五個子系統組成 程序排程，記憶體管理，虛擬檔案系統，網路介面，程序間通訊。1.程序排程 sched 控制程序對cpu的訪問。當需要選擇下乙個程序執行時，由排程程式選擇最值得執行的程序。可執行程序實際上是僅等待cpu資源的程序，如果某個程序在等待其它資源，則該程序是不可執行程序。l...
Linux核心結構
linux核心主要由五個子系統組成 程序排程，記憶體管理，虛擬檔案系統，網路介面，程序間通訊。1.程序排程 sched 控制程序對cpu的訪問。當需要選擇下乙個程序執行時，由排程程式選擇最值得執行的程序。可執行程序實際上是僅等待cpu資源的程序，如果某個程序在等待其它資源，則該程序是不可執行程序。l...