Re: [問題] 關於RTOS preemptive kernel實際排程的 …

看板ASM (組合語言)作者ggg12345 (ggg)時間14年前 (2010/02/17 23:21)推噓1(1推 0噓 2→)

留言3則, 1人參與討論串3/3 (看更多)

※ 引述《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

推

mimi0213

03/04 23:19, , 1^F

03/04 23:19, 1^F

→

mimi0213

03/04 23:22, , 2^F

03/04 23:22, 2^F

→

mimi0213

03/04 23:22, , 3^F

03/04 23:22, 3^F

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)