首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

计算机中断机制(2)

计算机中断机制(2)

中断与指令周期 有了中断以后,CPU可以与I/O操作一并运行。参考上图中的B部分。与A部分类似,用户程序在调用了写操作后进入I/O程序,不过这次I/O程序在完成准备阶段任务后便立即返回到用户程序,用户程序与I/O设备并发工作(KEMIN:细心想想,这种并发性是用户程序本身决定的,换个角度看,如果是读操作,那么用户程序要不要等呢?答案应该是肯定的,至少与读出数据相关的任务必须等,只是用户程序可执行另一个并发任务,比如显示一个读操作的进度条)。
b.上下文切换是多道程序的特征和必要。但是有一种切换迷惑了我们,就是协作式任务的切换,比如系统服务或硬件驱动调用。细心想想,其实切换的本质是换工作内容。由WORD切换到音乐播放器是进程切换;由WORD里的拼写检查到接受用户输入的切换是线程切换。而由音乐播放器解码到声卡驱动将解码数据输出的切换则是一种伪切换,它是一个无法分解的任务前后部分,但是因为要对硬件的保护而做成客户服务形式。这个过程中,音乐播放器的主线程被挂起,而声卡驱动输出可能不需要音乐播放器的主线程的任何信息(这就是所谓的无关上下文任务),完成后就绪(具体可能置一下音乐播放器的主线程某状态位)音乐播放器的主线程…… 2009-4-23 12:44

当外部设备完成了写操作,准备了接受处理器更多的数据时,设备的I/O模块(控制器)向处理器发出一个中断请求信号。如果中断响应的条件满足,处理器便挂起当前的用户程序(假设只有一个程序在计算机内执行),转向某特定中断处理程序(interrupt handler),完成中断处理后恢复先前用户程序的执行。图中用一个叉表示中断点,这个点发生的时刻是任意的。就是因为中断发生不可预见性,用户程序本身是无法进行中断现场保存及恢复,这个工作必须由处理器和操作系统(中断处理程序)负责。
CPU为了提供中断机制,CPU的指令周期(instruction cycle)增加了中断(判断)阶段(interrupt stage),如下图。在中断判断阶段,处理器检查是否有中断发生,根据引脚是否中断信号。如果没有中断等候(pending)处理,处理返回取指阶段(fetch stage),继续下一轮指令周期;如果有中断等候处理,那么处理器便挂起当前的用户程序并转中断处理程序。一般来说,中断处理程序是操作系统的一部分。中断处理程序一般会先判断中断源(determines the nature of XX)再作相应的处理。比如本例子中,处理程序会判断哪个I/O控制器发出的中断请求……

     b.又来了一个问题,跨进程(线程)的中断是怎样触发的?硬件中断有引脚,而用户进程要进入核态可以自己发出软中断,但是一个优先更高的线程(比如OS的进程调度线程)怎么打断当前进程,占用CPU的呢?那只有一种可能,就是CPU每执行一条指令后都会检查有没有优先更高的线程要中断处理,是这样的吗? 2009-4-13 11:34

很明显,中断调用与返回过程会有额外的开销(相对了同步的轮询)。不过相对于等待I/O操作,CPU完成中断现场保存与恢复和中断源的判断所需的指令时间是微不足道的。
中断处理过程 从中断产生的一刻开始,系统内(包括处理器和软件)会有一系列的事件发生。下图展示了这些事件发生的流程:
硬件事件
  • 设备向处理发生中断请求信号;
  • 在响应中断请求前,处理必须完成当前的指令执行任务;
  • 处理器在中断判断期(interrupt stage)检测到中断请求,然后发一个确认信号(acknowledgment signal )给中断设备;接到确认后,设备移去线路上的中断请求信号。
  • 中断响应的第一步是保存中断现场。为了能恢复中断现场,处理器至少保存程序状态字(program status word PSW)和程序计数器(program counter)的值。这些状态值会被压入系统控制堆栈(system control stack)
        P.S.请补充系统堆栈具体是什么?
  • 中断响应的第二步是载入中断处理程序。这个过程只需把中断处理程序的入口地址载入程序计数器即可。根据体系结构或操作系统设计的不同,可能有一个或多个入口地址(每种中断源一个)。如果有多个入口地址,处理器还得先判断哪一个地址才是。入口地址信息可能包含当初的中断请求信号中,也可能需要处理器查询所有设备而获得。


软件事件
  •      中断过程到这一步,虽然被中断的用户程序的程序计数器和程序状态字已经被保存到控制堆栈,但是被中断的用户程序的其它状态信息还是要被注意的。比如,处理器的寄存器内容要被保存,因为中断处理程序可能会用到这些值。中断处理程序的代码一开始就是负责保存这些状态信息(关于这些状态信息的具体详细,请参阅第三章 进程描述与控制)。下图A部分简要的展示了这个过程中的内容。用户程序在N地址处被中断,然后所有寄存器值和下一条指令的地址(N+1)总共M个字被压入控制堆栈。栈顶指针被更到新的位置,程序计数器也被更新为中断处理程序的首地址。


  • 下一步是中断处理正式开始。中断处理的指令(或者叫任务)包括检测设备状态、下达处理命令等等,根据中断处理任务的不同而不同。
  • 中断处理完成后进入中断现场的恢复——弹出控制堆栈的内容回原处。这些任务包含在中断处理程序中;
  • 中断处理最后一步是恢复原中断程序的程序状态字和程序计数器的值(KEMIN:不明白为什么中断现场恢复分两步讲)。
        为了正确地恢复原中断程序的执行,原中断程序的所有状态信息必须被保存起来,因为中断调用不是子程序调用,中断事件的发生是不可以预知的。
继承事业,薪火相传
返回列表