03/18

Hooks:
OS_CTX_SW_HOOK{

}
空的, 每次context switch發生就會呼叫一次, 讓user寫入事件用

進入第三章...
critical sections:
application本身在user mode下不能直接call enable interrupt and disable interrupt, 必須透過system call, 但在kernel下可以

可以用semaphore()或enable/disable interrupt來保護
semaphore(): 用約二三十行來保護資料
若只保護1行資料, 感覺上很大費周章
DI, EI: 只用兩行
效能較高(降低overhead)
但若保護的程式碼很長, 會使DI, EI的時間變久, 會讓有些interrput都無法執行

OS_ENTER_CRITICAL(); /*在此執行OS_TIME_DELAY();*/ OS_EXIT_CRITICAL();
這樣通常會讓系統crash掉, 唯讀x86不會, 因為context switch時會讓interrput再度打開

實做critical section的三種方法:
1.OS_CRITICAL_METHOD=1
最簡單的方法, 無使用到save & restore
func1(){
DI;
func2();
.../*離開critical section*/
EI;
}
func2(){
DI;
...
EI;
/*離開critical section*/
}
這樣會出問題, 所以call function時要先注意function內有無DI, EI
2.OS_CRITICAL_METHOD=2
PSW(processor status word)用於save & restore stacks
使用stack來實做nested interrput enable/disable interrupt
3.OS_CRITICAL_METHOD=3
PSW相較於method2不局限於存在stack, 而可以存在memory中
OSTaskChangePrio()
可改變task priority=task ID, 但更改可能造成某些程式不能跑(扯到task ID)

OSTaskDel(xxx)
xxx=OS_PRIO_SELF代表刪除自己
xxx=task ID 代表刪除task IDxxx的task
(task無法用returne關掉)

OSTimeDly(), OSTimeDlyHMSM(), OSFlagPend(), OSSemPend(), OSMboxPend(), OSQPend
均會使task進入到waiting Q中
OSTimeTick()會使task回到ready Q中

全部task都進入waiting Q怎麼辦?
ans: idle task永遠在ready Q

doubley linked的好處: delete方便

*OSTCBCur;//目前正在執行的task
*OSTCBFreeList;//指向TCB開頭
*OSTCBHighRdy;//priority最高的task
*OSTCBList;//all task均可由此list找到
*OSTCBPrioTbl[];//找TCB用
OSTCBTbl[];//預先配置好的TCB
*OSTCBCur;與*OSTCBHighRdy;只有在context switch時才會不一樣