作者ggg12345 (ggg)
看板ASM
標題Re: [問題] 關於RTOS preemptive kernel實際排程的 …
時間Wed Feb 17 23:21:50 2010
※ 引述《neutopia (journey)》之銘言：
: 現在在看 uC/OS已經移植在某chip上的source code
: 發現和書上講的原理有一點差異
: 書上是說只要ISR做完時就會重新排程，由priority最高的task去執行
: 我看的Code只有在system tick timer的ISR裡有作schedule
: 其他都沒有
======
記得不太清楚了, 有誤請高人更正.
Intel 的 cpu 藉 interrupt controller 對多個 irq line 擇一
產生給 cpu 的中斷請求與中斷向量代號. 當處理完 ISR 之後必須
執行清除 interrupt controller 狀態的動作(out 某個 port),
且必須執行 iret 指令改變 cpu 的 int flag.
pre-emptive scheduling 就是 ISR 只對外部事件的後續動作只設
定對應的 event flag, 常用的技巧是配合 iret 以改變 stack 內
return address 的形式, 在執行 iret 之後, 不回被中斷的 task
而是逕自進入 scheduler/dispatcher , 再由 event priority 決
定該執行那個後續的 task.
有些 I/O 硬體沒有使用 DMA 裝置, 中斷一發生就必須從對應的
input port 取出資料, 太慢處理就會被後續的 input 覆蓋, 這種
I/O 的中斷程式與快速處理就會在 ISR 內直接用程式完成搬移動
作, 做完設定狀態記號後, 就還回被中斷的程式.
: 我的疑問為：哪些中斷做完要排程是由programmer自己決定嗎？
: 一堆週邊(Ethernet, UART, SPI, Timer)的中斷做完後要不要重新排程
: 應該是看使用上的需要吧...
: 而這也會影響到critical section是把所有中斷都disable或者只把有重新排程
: 的中斷disable...
: 不知我的想法是否正確？
中斷發生, 進入被 ISR 處理時, 都是已變成 disable interrupt 狀
態, ISR 是否決定要 Enable interrupt 就看是否有沒有 critical
section 的 mx 限制, 若允許被更高優先的硬體中斷搶先, 就是釋出
cpu 的控制權, 允許更緊急的對應處理.
通稱的 scheduler/dispatcher 是指 硬體 priority interrupt
controller 之外, 執行完 ISR 與 iret 後接續的軟體排程.
non-preemptive scheduling 就是 ISR 不會提前釋放 cpu 控制權,
在最後執行 iret 之後仍會回到被中斷的 task 繼續執行.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.115.4.12
1F：推 mimi0213:我記得實做上除了第一個process外，應該是用jmp的方式作 03/04 23:19
2F：→ mimi0213:context switch。而iret好像不會儲存現在context的狀態回 03/04 23:22
3F：→ mimi0213:tss segment?? 03/04 23:22
X86 real mode 的 iret 僅是 return from interrupt 只會影響受到從 stack 還原
的 PSW, 再從 stack 取出 cs:ip 回去執行.
X86 protection mode 有硬體支援的 Task Switch . 不過, OS 的 context switch
仍然需要軟體協助更多狀態的 save/restore. 所以有些 os 不使用硬體協助, 全部
都用 software 做 context switch 動作, 一般都跟 scheduler/dispatch 模組有關.
protection mode 下的 iret 受 nested task flag 決定是否要在 iret 之後進行
硬體的task switch. 若要進行, 則硬體透過 task state segment 進行硬體的 task
state save/restore 動作, 由於變動了 stack 及 return-address 執行 iret 動作
就完成 task switch.
※ 編輯: ggg12345 來自: 140.115.4.12 (03/09 09:03)