首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件开发 >

DPC(推延过程调用)的技术细节

2013-11-02 
DPC(延迟过程调用)的技术细节-DPC(延迟过程调用)的细节NTINSIDER,16卷,1期,1至2月2009延迟过程调用(DPC)是

DPC(延迟过程调用)的技术细节

-DPC(延迟过程调用)的细节

NTINSIDER,16卷,1期,1至2月2009


延迟过程调用(DPC)是一种Windows常用功能。用途是广泛和多样的,但最常用的是我们通常所说的“ISR完成”和WindowsTimer底层技术。

   如果DPC常用,为什么还要写此篇?我们发现,大多数人并不真正了解DPC工作的底层实现细节。并且,事实证明,一个深入的理解,在选择选项创建DPC的调试方案中也至关重要。

简介

本文并不意味着是一个全面的DPC应用文档。它假定读者已经知道DPC是什么,更甚,在驱动中已作应用。如果你不属于这一类,查阅MSDN吧。

此外,ThreadedDPCs,这是一种特殊类型的DPC。可用于WindowsVista和以后,将不包括任何细节。

作为我们讨论的基础,让我们简要回顾一些基本的DPC概念。

DPC的定义是一种可以请求一个回调到任意线程上下文,在dispatch级别的IRQL。DPC对象本身仅是一个list_entry数据结构,一个回调指针,一些回调上下文,和一位的控制数据:

typedef struct _KDPC {
    UCHAR Type;
    UCHAR Importance;
    USHORT Number;
    LIST_ENTRY DpcListEntry;
    PKDEFERRED_ROUTINE DeferredRoutine;
    PVOID DeferredContext;
    PVOID SystemArgument1;
    PVOID SystemArgument2;
    __volatile PVOID DpcData;
} KDPC, *PKDPC, *PRKDPC;

你来初始化一个DPC对象采用keinitializedpc和队列keinsertqueuedpc此DPC对象。驱动程序使用DPC进行更多的工作比是适当的一个中断服务程序,DPC的对象嵌入在设备对象。使DPC对象被排队通过调用函数IoRequestDpc(在内部调用keinsertqueuedpc)。一旦排到队列,在将来的某个时候你的DPC例程将被任意线程上下文IRQL级别 dispatch_level调用。

    有了这些基本的信息,我们现在可以覆盖DPC排队列细节都和传输机制。这将导致我们讨论如何控制DPCs行为,这些选项有什么影响。

DPC队列

如前所述,DPCs排列(直接或间接)通过KeInsertQueueDpc DDI:
NTKERNELAPI

BOOLEAN
keinsertqueuedpc(
__inout prkdpc DPC,
__in_opt PVOID systemargument1,
__in_opt PVOID systemargument2
);


DPCs实际上是排队到一个特定的处理器,这是通过将DPC对象为DPC连接到DPC队列,位于目标处理器控制块(PRCB)。对OS而言确定该DPC对象队列,对处理器是相当容易的。默认情况下,DPC是排队列到处理器,KeInsertQueueDpc被调用(“当前处理器”)。然而,驱动可以指示一个给定的处理器被用于一个特定的DPC对象,使用例程KesetTargetProcessorDpc。

在一个特定的处理器用WinDbg查看DPC列表很容易。当DPC列表实际上是包含在PRCB,PRCB是处理器的控制区域的扩展(PCR)。通过观察PCR!PCR命令我们能看到的任何DPC目前处理器的队列:

0:kd> !pcr 0
KPCR for Processor 0 at ffdff000:
    Major 1 Minor 1
 NtTib.ExceptionList: 8054f624
     NtTib.StackBase: 805504f0
    NtTib.StackLimit: 8054d700
  NtTib.SubSystemTib: 00000000
       NtTib.Version: 00000000
   NtTib.UserPointer: 00000000
       NtTib.SelfTib: 00000000

            SelfPcr: ffdff000
               Prcb: ffdff120
               Irql: 00000000
                IRR: 00000000
                IDR: ffffffff
       InterruptMode: 00000000
                IDT: 8003f400
                GDT: 8003f000
                TSS: 80042000

      CurrentThread: 8055ae40
          NextThread: 81bc0a90
          IdleThread: 8055ae40

           DpcQueue:  0x8055b4a0 0x805015ae [Normal]nt!KiTimerExpiration
                     0x81b690a4 0xf9806990 [Normal] atapi!IdePortCompletionDpc
                     0x818a12cc 0xf96c5ee0 [Normal] NDIS!ndisMDpcX

   要注意的是,一旦一个DPC对象已排队列到一个处理器,再试图对此DPC排队列被忽略,直到DPC对象已出队(Windows的回调函数的执行)。这就是keinsertqueuedpc返回的布尔值的意义。

 

TRUE意味着Windows已排队此DPC到目标处理器,FALSE意味DPC对象已排队到另一些处理器。从编程的角度来看,作为数据结构DPC只有一个LIST_ENTRY域,因此一次只能出现在一个单一的队列。

关于优先权?

在DPC在那里被放置于目标处理器? DPC List是一个有趣的问题。一个DPC对象插入到目标处理器的开始或结束? DPC List优先功能的一个方面。你可以设置一个给定的DPC对象重要性,使用函数kesetimportancedpc。这个DDI让你表明DPC对象是低,中,或高重要性。同时,在Vista中,以后你可以设置的重要性“中高”。低,中,中高重要性和被放置在DPC队列的末尾,而高的重要性,被放置在队列的前面。在这一点上,问你自己,“在低,中和中高重要性有什么区别?”,我们会很快回答这个问题。

Dispatch_level软件中断

一旦DPC排队到目标处理器,一个dispatch_level软件中断通常在处理器生成的。选择是否请求dispatch_level软件中断时,DPC对象是排队在很大程度上是基于四个因素:重要性的DPC,DPC处理器的目标,在目标处理器的DPC列表的深度,和在目标处理器的DPC列表“流失率”。

如果DPC对象的目标处理器是目前的处理器,该dispatch_level软件中断请求发生,如果DPC对象是除了low之外的重要性。对low重要性DPC,软件中断发生,如果O / S认为处理器没有服务DPCs足够快,要么因为DPC队列已成为大或不以足够快的速度。如果这些都是真的,中断请求即使DPC是low重要性。

    如果对DPC的目标处理器不是当前的处理器,其决策过程是不同的。因为请求中断的处理器将涉及昂贵的处理器间中断(IPI)的情况下,它是所要求的限制。在Vista中,IPI请求只会如果DPC是高重要性或如果在目标处理器的DPC队列已变得太深。Vista添加中高重要性DPCs检查和进一步降低IPIS数量要求目标处理器被闲置的dispatch_level软件中断请求(见一个高层次的分解表1)。


DPC传递:

一旦DPC已排队到处理器,在某种程度上它必须出队和回调执行。记住,有两种情况,在DPC排队到处理器的出现,无论是否dispatch_level软件中断。

从软件断服务程序传递

为了让事情简单,我们将限制讨论,排队DPC对象到当前的处理器的情况下。从IRQL级别 dispatch_level软件中断请求开始。当时keinsertqueuedpc调用,有两种情况下的系统可能是:首先将运行在一个IRQL小于dispatch_level,在这种情况下,dispatch_level中断会立即交付。第二个案例将如果当前处理器的IRQL > = dispatch_level,在这种情况下,中断将保持等待直到IRQL即将回到<dispatch_levelIRQL。

在任一情况下,曾经为dispatch_level服务程序中断开始执行,它会检查是否有排队和当前处理器。如果DPC队列非空,Windows将在从服务例程返回循环和完全运行DPC列表流。

在排放前DPC列表,要确保它的DPC例程运行在一个新的执行堆栈。这可能会降低发生堆栈溢出的情况下,当前堆栈没有多少剩余空间。因此,每一个PRCB还包含一个指针指向先前分配的DPC堆栈,Windows切换到在调用任何DPCs之前:

0: kd> dtnt!_KPRCB DpcStack
   +0x868 DpcStack : Ptr32 Void

 如果我们在一个DPC程序设置断点,将看到调试器中的开关的证据。在这里,我们选择了从ATAPI驱动一个DPC:

0: kd> bp atapi!IdePortCompletionDpc
0: kd> g
Breakpoint 1 hit
atapi!IdePortCompletionDpc:
f9806990 8bff           mov     edi,edi
0: kd> k
ChildEBP RetAddr  
f9dc7fcc 80544e5fatapi!IdePortCompletionDpc
f9dc7ff4 805449cbnt!KiRetireDpcList+0x61
f9dc7ff8 f9a2b9e0nt!KiDispatchInterrupt+0x2b
WARNING: Frame IP not in any known module. Following frames may be wrong.
805449cb 00000000 0xf9a2b9e0

 注意到奇怪的调用堆栈,似乎在KiDispatchInterrupt调用之后消失。问题是,WinDBG已不再能够清晰显示调用堆栈,由于堆栈交换。我们在这里看到的是DPC堆栈的调用堆栈。如果我们尝试匹配的EBP地址显示与当前堆栈限制,我们将看到差异:

 

 

0: kd> !thread
THREAD 81964770  Cid 028c.02b8  Teb:7ffd8000 Win32Thread: e1873008 RUNNING on processor 0
IRP List:
    8195b870: (0006,0190) Flags:00000970  Mdl: 00000000
    819128b0: (0006,0190) Flags:00000970  Mdl: 00000000
Not impersonating
DeviceMap                e1001980
OwningProcess           818d5978      Image:         csrss.exe
AttachedProcess         N/A           Image:         N/A
Wait Start TickCount     6779           Ticks: 0
Context Switch Count     4104                LargeStack
UserTime                 00:00:00.000
KernelTime               00:00:00.265
Start Address 0x75b67cd7
Stack Init f9a2c000 Current f9a2ba58 Base f9a2c000 Limit f9a29000 Call0

从空闲(Idle)线程传递:但对于那些低重要性和或有目标DPC不要求dispatch_level软件中断?谁处理这些?嗯,实际上有两种方式,他们会处理的。另一个DPC会沿着这将要求dispatch_level中断,DPC将被随后的流水队列拾起,或空闲循环会出现,请注意,DPC队列是非空的。

部分空闲循环的工作是检查DPC队列和确定它是否为空。如果发现队列不是空的,它开始流水队列采用出队头并调用回调函数。我们可以在不同的调用堆栈看到这些。但使用前例相同的DPC程序:

Breakpoint 1 hit
atapi!IdePortCompletionDpc:
f98069908bff           mov     edi,edi
0:kd> k
ChildEBPRetAddr  
8055042880544e5f atapi!IdePortCompletionDpc
8055045080544d44 nt!KiRetireDpcList+0x61
8055045400000000 nt!KiIdleLoop+0x28

 

Idle 循环自己使用很少的线程堆栈,未用到很多地俄Swappingstacks。

结论:希望澄清了一些DPC误解,它们是如何被系统处理。

 

热点排行