阅读:1992回复:13
是否所有的dpc例程都运行在dispatch_level上呢??给分
看了art baker的2000设备驱动程序设置指南,说中断服务历程的DPC运行在dispatch_level。
DPC历程好像有很多,像计时器也有DPC历程(通过KeSettimer即可设置),这个dpc历程是不是也运行在dispatch_level上呢??只有这样才能抢夺运行在passive_level上历程的cpu以得到执行? |
|
沙发#
发布于:2005-01-28 16:15
[quote][quote]谢谢您热心的回答!!给分:))) 我觉得应该作为整体理解,上下文可以理解成一个进程,只看到用户端。应加上核心端,另外还有用户堆栈,核心堆栈,这个很重要。当然最重要的是页目录,页表映射。 [/quote] 上下文,一般指的是线程的上下文,因为Windows 2k系统调度的单位是 thread而不是process,所以在调度切换thread的时候,会导致当前的thread的上下文被切换了。thread的上下文是指thread运行环境,如: stack,各种registers等等。 [/quote] 页表等是针对进程的,线程共享进程的资源,如果系统在一个进程的几个线程切换,则不会切换上下文,也不会切换CR3 |
|
|
板凳#
发布于:2005-01-28 16:08
[quote]谢谢您热心的回答!!给分:))) 我觉得应该作为整体理解,上下文可以理解成一个进程,只看到用户端。应加上核心端,另外还有用户堆栈,核心堆栈,这个很重要。当然最重要的是页目录,页表映射。 [/quote] 上下文,一般指的是线程的上下文,因为Windows 2k系统调度的单位是 thread而不是process,所以在调度切换thread的时候,会导致当前的thread的上下文被切换了。thread的上下文是指thread运行环境,如: stack,各种registers等等。 |
|
|
地板#
发布于:2005-01-27 11:20
谢谢您热心的回答!!给分:))) 我觉得应该作为整体理解,上下文可以理解成一个进程,只看到用户端。应加上核心端,另外还有用户堆栈,核心堆栈,这个很重要。当然最重要的是页目录,页表映射。 |
|
|
地下室#
发布于:2005-01-26 18:50
谢谢您热心的回答!!给分:))) 这样理解不好 |
|
|
5楼#
发布于:2005-01-26 18:20
谢谢您热心的回答!!给分:)))
上下文可以理解成一个进程吗?或者是一个线程? |
|
6楼#
发布于:2005-01-26 11:20
谢谢阿。 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是一个整体。 |
|
|
7楼#
发布于:2005-01-25 17:37
谢谢阿。
我关注的不是分业与否,确切地说,我知道非分业内存不会被交换到磁盘上,也不能再dispatch_level及其以上访问分业内存。 我想了解的是: 您所说的内核中不切换上下文是指中断到来的时候,os不保存当前的执行的环境?? 还有ddk中常说的arbitary context和nonarbitary context是指的什么东东呢?? “所有的用户进程对应的核心是相同的,核心不切换。“这句话意思是说用户进程对应了同一个驱动,驱动不切换?能否解释一下? |
|
8楼#
发布于:2005-01-25 15:58
我现在设置了一个带DPC例程的计时器,在计时器超时的时候,DPC例程得到执行。 在内核中是不切换上下文的,上下文只对用户程序说的。 至于OS保存上下文(此上下文包含这块内存吗),OS切换页目录不会影响内核地址映射,所有的用户进程对应的核心是相同的,核心不切换。你的这块内存是非分页内存,我自我觉得它不会被交换到磁盘上,若是分页内存,必须运行在虚拟内存管理器运行的级别之下,否则,一旦换出,你要写内存,虚拟内存管理器得不到控制,不能将其换入,这样要出问题。 |
|
|
9楼#
发布于:2005-01-24 16:02
我现在设置了一个带DPC例程的计时器,在计时器超时的时候,DPC例程得到执行。
请问这个DPC例程运行在Dispatch_level上吗? 如果是的话,它就会比分发例程有更高得中断级。 现在分发例程要read一块非分页内存,此时计时器超时,那正在执行得分发例程被中断。OS保存上下文(此上下文包含这块内存吗),并调用DPC例程,DPC例程中要修改这一块非分页内存。这样子的话,会否导致分发例程重新得到CPU得时候出问题?因为非分页内存已经被改变了,从而导致了上下文得改变。 |
|
10楼#
发布于:2005-01-22 15:21
在dispatch_level上运行的代码肯定比passive_level上的要紧急了,dispatch例程都在passive_level上进行,所以DPC例程比dispatch例程的中断级高。 中断调度是依据优先级别的,中断级高可以中断中断级低的,如果程序运行在低优先级下就容易被中断 |
|
|
11楼#
发布于:2005-01-22 10:41
在dispatch_level上运行的代码肯定比passive_level上的要紧急了,dispatch例程都在passive_level上进行,所以DPC例程比dispatch例程的中断级高。 DPC虽然不如ISR等紧急,但毕竟是驱动程序的一部分,也还是要尽快完成。当然,微软未公开的自己的DPC还要在比dispatch_level更高级上运行,但你我却都做不到。在dispatch_level有同步信号量,所以可以控制不同DPC之间的执行顺序,此之谓方便调度。 |
|
|
12楼#
发布于:2005-01-21 16:42
在dispatch_level上运行的代码肯定比passive_level上的要紧急了,dispatch例程都在passive_level上进行,所以DPC例程比dispatch例程的中断级高。
由于线程调度器在dispatch_level运行,所以便于调度?即使DPC例程运行在passive_level上也同样的调度啊。 |
|
13楼#
发布于:2005-01-21 15:22
应该是的,因为DPC不太紧急,紧急的部分早执行过了,而且在这一level还便于调度
|
|
|