b.上下文切换是多道程序的特征和必要。但是有一种切换迷惑了我们，就是协作式任务的切换，比如系统服务或硬件驱动调用。细心想想，其实切换的本质是换工作内容。由WORD切换到音乐播放器是进程切换；由WORD里的拼写检查到接受用户输入的切换是线程切换。而由音乐播放器解码到声卡驱动将解码数据输出的切换则是一种伪切换，它是一个无法分解的任务前后部分，但是因为要对硬件的保护而做成客户服务形式。这个过程中，音乐播放器的主线程被挂起，而声卡驱动输出可能不需要音乐播放器的主线程的任何信息（这就是所谓的无关上下文任务），完成后就绪（具体可能置一下音乐播放器的主线程某状态位）音乐播放器的主线程…… 2009-4-23 12:44

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

• 设备向处理发生中断请求信号；
• 在响应中断请求前，处理必须完成当前的指令执行任务；
• 处理器在中断判断期(interrupt stage)检测到中断请求，然后发一个确认信号（acknowledgment signal ）给中断设备；接到确认后，设备移去线路上的中断请求信号。
• 中断响应的第一步是保存中断现场。为了能恢复中断现场，处理器至少保存程序状态字（program status word PSW）和程序计数器(program counter)的值。这些状态值会被压入系统控制堆栈（system control stack）
      P.S.请补充系统堆栈具体是什么？
• 中断响应的第二步是载入中断处理程序。这个过程只需把中断处理程序的入口地址载入程序计数器即可。根据体系结构或操作系统设计的不同，可能有一个或多个入口地址（每种中断源一个）。如果有多个入口地址，处理器还得先判断哪一个地址才是。入口地址信息可能包含当初的中断请求信号中，也可能需要处理器查询所有设备而获得。

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

  

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