作者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)