是否所有的dpc例程都运行在dispatch_level上呢？？给分

看了art baker的2000设备驱动程序设置指南，说中断服务历程的DPC运行在dispatch_level。

DPC历程好像有很多，像计时器也有DPC历程（通过KeSettimer即可设置），这个dpc历程是不是也运行在dispatch_level上呢？？只有这样才能抢夺运行在passive_level上历程的cpu以得到执行？

应该是的，因为DPC不太紧急，紧急的部分早执行过了，而且在这一level还便于调度

在dispatch_level上运行的代码肯定比passive_level上的要紧急了，dispatch例程都在passive_level上进行，所以DPC例程比dispatch例程的中断级高。
由于线程调度器在dispatch_level运行，所以便于调度？即使DPC例程运行在passive_level上也同样的调度啊。

在dispatch_level上运行的代码肯定比passive_level上的要紧急了，dispatch例程都在passive_level上进行，所以DPC例程比dispatch例程的中断级高。
由于线程调度器在dispatch_level运行，所以便于调度？即使DPC例程运行在passive_level上也同样的调度啊。

DPC虽然不如ISR等紧急，但毕竟是驱动程序的一部分，也还是要尽快完成。当然，微软未公开的自己的DPC还要在比dispatch_level更高级上运行，但你我却都做不到。在dispatch_level有同步信号量，所以可以控制不同DPC之间的执行顺序，此之谓方便调度。

在dispatch_level上运行的代码肯定比passive_level上的要紧急了，dispatch例程都在passive_level上进行，所以DPC例程比dispatch例程的中断级高。
由于线程调度器在dispatch_level运行，所以便于调度？即使DPC例程运行在passive_level上也同样的调度啊。

中断调度是依据优先级别的，中断级高可以中断中断级低的，如果程序运行在低优先级下就容易被中断

我现在设置了一个带DPC例程的计时器，在计时器超时的时候，DPC例程得到执行。
请问这个DPC例程运行在Dispatch_level上吗？
如果是的话，它就会比分发例程有更高得中断级。

现在分发例程要read一块非分页内存，此时计时器超时，那正在执行得分发例程被中断。OS保存上下文（此上下文包含这块内存吗），并调用DPC例程，DPC例程中要修改这一块非分页内存。这样子的话，会否导致分发例程重新得到CPU得时候出问题？因为非分页内存已经被改变了，从而导致了上下文得改变。

我现在设置了一个带DPC例程的计时器，在计时器超时的时候，DPC例程得到执行。
请问这个DPC例程运行在Dispatch_level上吗？
如果是的话，它就会比分发例程有更高得中断级。

现在分发例程要read一块非分页内存，此时计时器超时，那正在执行得分发例程被中断。OS保存上下文（此上下文包含这块内存吗），并调用DPC例程，DPC例程中要修改这一块非分页内存。这样子的话，会否导致分发例程重新得到CPU得时候出问题？因为非分页内存已经被改变了，从而导致了上下文得改变。

在内核中是不切换上下文的，上下文只对用户程序说的。
至于OS保存上下文（此上下文包含这块内存吗），OS切换页目录不会影响内核地址映射，所有的用户进程对应的核心是相同的，核心不切换。你的这块内存是非分页内存，我自我觉得它不会被交换到磁盘上，若是分页内存，必须运行在虚拟内存管理器运行的级别之下，否则，一旦换出，你要写内存，虚拟内存管理器得不到控制，不能将其换入，这样要出问题。

谢谢阿。
我关注的不是分业与否，确切地说，我知道非分业内存不会被交换到磁盘上，也不能再dispatch_level及其以上访问分业内存。
我想了解的是:
您所说的内核中不切换上下文是指中断到来的时候，os不保存当前的执行的环境？？
还有ddk中常说的arbitary context和nonarbitary context是指的什么东东呢？？

“所有的用户进程对应的核心是相同的，核心不切换。“这句话意思是说用户进程对应了同一个驱动，驱动不切换？能否解释一下？

谢谢阿。
我关注的不是分业与否，确切地说，我知道非分业内存不会被交换到磁盘上，也不能再dispatch_level及其以上访问分业内存。
我想了解的是:
您所说的内核中不切换上下文是指中断到来的时候，os不保存当前的执行的环境？？
还有ddk中常说的arbitary context和nonarbitary context是指的什么东东呢？？

“所有的用户进程对应的核心是相同的，核心不切换。“这句话意思是说用户进程对应了同一个驱动，驱动不切换？能否解释一下？

ddk中常说的arbitary context是说在kernel-mode中某驱动程序运行时并不知道user_mode中是哪个应用程序的进程在运行。nonarbitary context正相反，在kernel-mode中某驱动程序运行时知道user_mode中是哪个应用程序的进程在运行，而且在这个时候，OS是不会切换user-mode中的那个应用程序进程为其它应用程序进程的。
切换上下文只切换user-mode上下文，kernel-mode中的内存地址永远都是不变的，唯一的。而且不管是哪个user-mode进程看到的kernel-mode内存地址(一般是2G以上)都是完全相同的。
中断到来的时候，若此时在user-mode中运行，其它user-mode进程有机会在中断处理完成后成为user-mode中的当前进程，即发生上下文切换。中断到来的时候，若此时在kernelr-mode中运行，先处理中断，然后再返回到中断发生的地方继续执行。

所有的用户进程对应的核心是相同的，核心不切换。“这句话意思是说用户进程对应了同一个驱动，驱动不切换？能否解释一下？
所有的用户进程可以看到OS中的所有驱动，只是可能无权限访问而已。想象OS kernel是一个整体。

谢谢您热心的回答！！给分:)))
上下文可以理解成一个进程吗？或者是一个线程？

谢谢您热心的回答！！给分:)))
上下文可以理解成一个进程吗？或者是一个线程？


 

这样理解不好

谢谢您热心的回答！！给分:)))
上下文可以理解成一个进程吗？或者是一个线程？


 

我觉得应该作为整体理解，上下文可以理解成一个进程，只看到用户端。应加上核心端，另外还有用户堆栈，核心堆栈，这个很重要。当然最重要的是页目录，页表映射。

[quote]谢谢您热心的回答！！给分:)))
上下文可以理解成一个进程吗？或者是一个线程？


 

我觉得应该作为整体理解，上下文可以理解成一个进程，只看到用户端。应加上核心端，另外还有用户堆栈，核心堆栈，这个很重要。当然最重要的是页目录，页表映射。 [/quote]

上下文，一般指的是线程的上下文，因为Windows 2k系统调度的单位是
thread而不是process,所以在调度切换thread的时候，会导致当前的thread的上下文被切换了。thread的上下文是指thread运行环境，如：
stack,各种registers等等。

[quote][quote]谢谢您热心的回答！！给分:)))
上下文可以理解成一个进程吗？或者是一个线程？


 

我觉得应该作为整体理解，上下文可以理解成一个进程，只看到用户端。应加上核心端，另外还有用户堆栈，核心堆栈，这个很重要。当然最重要的是页目录，页表映射。 [/quote]

上下文，一般指的是线程的上下文，因为Windows 2k系统调度的单位是
thread而不是process,所以在调度切换thread的时候，会导致当前的thread的上下文被切换了。thread的上下文是指thread运行环境，如：
stack,各种registers等等。 [/quote]
页表等是针对进程的，线程共享进程的资源，如果系统在一个进程的几个线程切换，则不会切换上下文，也不会切换CR3