第三章 系统机制(p96-106) 2009--6-19

1. 使用内核性能剖析工具可以分析系统在那个函数比较花费时间。。工具是 Kernrate。。。。

2. 在Dpc/Dispatch级别上运行的代码，有一个重要的限制是： 不能等待任何对象，因为等待对象会导致新的线程调度。同时带来的副作用是不能有页面错误。

所以这些代码必须运行在非分页内存中。（为什么有这样限制还没想明白？）

3. 中断对象。。充分证明了windows就是对象的集合。。

a. 设备驱动程序可以为他们的设备注册ISR（怎么注册？要看 source code ）这个就是中断对象。中断对象中包含了 服务例程的起始地址(routine address)

中断对象运行的IRQL 。。 中断对象的自旋锁。   还有一些从中断处理模板code 放在 DispatchCode【106】变量中。

b. 在Dispatchcode中调用了 中断分发器。。 内核中中断分发器的例程： KiInterruptDispatch  （只适合一个注册了一个中断对象的中断向量） 和KiChainedDispatch (链式分发 。。）

7. 中断控制流：

 

7. 中断对象的结构

typedef  struct

{

  .....

ServiceRoutine 

ServiceContext

SpinLock

IRQL

DispatchCode【106】;

};

将ISR与只能中断级别联系起来的 函数： IoConnectInterrupt。

 8 软件中断

主要包括：

   线程分发 DPC  定时器到期  APC  异步I/O 。

DPC机制

我理解的DPC机制：

因为设备驱动的中断服务例程都工作在DPC/Dispatch级别之上。。。这个时候为了使得本来应该在ISR中完成但是又不是很紧迫的任务 放到 DPC队列中，而ISR执行完紧迫任务后，便触发一个软中断，（设置PRCB的标志位），然后中断服务例程便返回了。。 等处理器的IRQL降下来的时候，便去检查DPC队列，如果有请求 ，便执行 。

 

DPC请求都对应一个DPC对象。。。该对象中最重要的是 该DPC需要执行的系统函数地址 。。

线程分发 。。。 时钟中断。。。 都是采用 DPC机制完成的。。

关于上面的两个部分感觉原著上说的挺好：

 

 

 

关于DPC机制的实现 ：

http://book.csdn.net/bookfiles/1044/100104431308.shtml  这个ReactOS的实现 。。 我感觉 和windows的真正的实现有些出入 。。

 

要调试  看下windows怎么实现的。