chapter 5(cont)

※ OSTimeTick()
1. OSTCBList會把正在執行的task串成一列，
最後一個task一定是idle task，因為在新增刪除task時一定是從頭，
系統裡面第一個task又是idle task，造成idle task放最後一個。
2. 因此可以從頭往下找，找到idle task為止，到idle task就不執行，
因為idle task本身不會呼叫sleep，永遠都是ready。
3. (不太重要)
去判斷每個TCB裡的欄位Dly的值，數字代表要等多久。
每次執行-1，當有1變到0的時候，會把task擺到readyQ裡，
在此時，如果有人去suspend住某個task時，
他將不會變成0，至少會是1，為了避免會睡不到1個tick。
4. ptcb->OSTCBStat & OS_STAT_SUSPEND == 0x00
可能要等待多個動作(所有條件)滿足才能往下執行。

※ OSTimeDlyResume()
1. 把剩下的tick歸0
2. 把task搬到rdyQ

※ OSTimeGet() & OSTimeSet()
要包在critical section裡

※ 解決Delay a task until tx的問題 I
不可以使用第一種critical method包在critical section裡
因為要等時間中斷，但是前面卻已經把interrupt關掉，所以錯

※ 解決Delay a task until tx的問題 II
使用第二種critical method包在critical section裡，
頂多會有interrupt進來，假設ISR程式碼都很短，影響不大。
影響比較大的是high priority task，因為sched被lock住，
因此不會context switch

※ 解決Delay a task until tx的問題 III
自己寫，利用第一種critical method但是把巢狀拿掉。

※ OSTimeTick演算法的缺點
時間複雜度是系踏(n)，n是系統裡面所有task的數量。

※ BSD的實作方法
用link-list將timer control block(時間控制單元)串起來，
5 1 0 3 -> 5 6 6 9
好處：每次一個時間中斷，往上呼叫的時候，只要對第一項做-1就好
壞處：新增比較麻煩，有時OSTimeDly的時間複雜度比較高
結論：還是比uCOSII好
linux演算法更複雜，介於BSD和uCOSII之間