uc/os-ii的任務一般格式為：
void taskn(void *pdata) }
ucos-ii是基於任務優先順序搶占式任務排程法的，就是核心在管理排程時，呼叫任務切換函式（一般為ssched()），在該函式中將此時已處於就緒狀態（條件一）並且為最高優先順序（條件二）的任務的儲存於其棧中的相應資訊壓入cpu暫存器中（軟中斷完成），然後cpu開始執行該任務的**。
核心是何時進行任務排程的呢？雖然uc/os-ii是可被剝奪資源的核心（高優先順序可強行占有低優先順序正在使用的資源），但此事發生的前提是核心實時"檢測"到了更高就緒的優先順序了，那麼核心是怎樣來實時檢測的呢？
帶著這個問題讓我們再來看看任務的結構——裡邊有函式ostimedly(os_ticks_per_sec)，一看就知道這是個延時函式，除了延時外它還會有其他用途呢？經檢視其原始碼了解到裡邊有一條**：ossched()，對，函式ostimedly()的作用就是將此時正在執行的函式掛起（儲存任務控制塊os_tcb中的相應資訊）（任務控制塊os_tcb是系統分配給每個任務的資訊儲存單元），然後呼叫函式ossched()進行任務切換，進而執行就緒的最高優先順序任務。此刻，我們了解到ucos-ii的任務切換是在執行的任務中呼叫延時函式ostimedly()進行的。
現在，還有乙個問題還沒解決，就是當延時到了，核心如何將資源返還給被延時掛起的任務？
我們先來了解一下任務可控制塊（os_tcb）,任務控制塊是乙個資料結構，當任務的cpu使用權被剝奪時，uc/os-ii用它來儲存該任務的狀態。當任務重新得到cpu使用權時，任務控制塊確保任務從當時被中斷的那一點絲毫不差地繼續執行。os_tcb全部駐留在ram中。在os_tcb中有一項時間延時項ostcbdly，呼叫函式ostimedly()過程中有一步驟就是給ostcbdly賦延時值。uc/os—ii中有函式ostimtick()，叫時鐘節拍函式，它的一項工作就是給每個使用者任務控制塊os_tcb中的時間延遲項ostcbdly減1（如果該項不為零），當某項任務的任務控制塊中的時間延時項ostcbdly減為0時，這個任務就進入了就緒態，等待任務切換。而時鐘節拍函式ostimtick()的呼叫函式由時鐘節拍中斷服務函式ostickisr()呼叫（或與相應函式配合呼叫）。
現在，我們來理一下思路：任務呼叫函式ostimedly()，掛起任務和呼叫切換函式並設定延時時間——>週期性呼叫時鐘節拍中斷服務函式ostickisr()進行任務延時計數（ostimtick()完成），延時到時呼叫任務切換函式ossched(),進行任務切換。
綜上，任務切換有兩種途徑——時鐘節拍中斷服務函式ostickisr()進行切換，任務中呼叫時間延遲函式ostimedly()進行切換。
從先後順序來說，應該是ostimedly()先發生（設定ostcbdly），才會有時鐘節拍中斷函式ostickisr()進行切換的動作發生。
golang排程過程
1.執行時系統相關模組 這一節只講述排程系統。2.與排程相關的有下列資料有 1 全域性表就不用多解釋，排程器不是乙個專門的執行緒，而是一種資源，每個m都可能會對其進行查詢，如 m的呼叫的時候，會首先查詢排程器中的可執行佇列g，然後查詢本地p執行佇列 在m不夠的時候，會首先排程器空閒的m列表中查詢 在...
uCOS II的任務排程和時鐘
在ucos ii中，任務切換只是簡單的將處理器暫存器儲存到將被掛起的任務的堆疊中，並且將更高優先順序的任務從堆疊中恢復出來，或者叫copy複製出來，處於就緒狀態的任務的堆疊結構看起來就像剛發生過中斷並將所有的暫存器儲存到堆疊中的情形一樣。換句話說，ucos ii要執行處於就緒狀態的任務必須要做的事情...
我看ucosii的任務排程
以前只是知道每個task的格式是 void mystask void pd while 1 void mytask void pd 實際上，ostimedly nticks 裡就包含了一次任務排程，否則任務是不會自己進行排程的。而排程的程式os sched 中就只是查詢出優先順序最高的已經就緒的任務...