DPC (deferred procedure call)

NTDEV
1

Hi everyone I spent a lot of time on dpc (deferred procedure call), but it wasn’t clear to me. Why is it used and what is its function? Can you give an example?

2

well, a lot could be written on this topic and much has been written already - please search the archives . if you care about this subject it seems clear that you must have a real device that raises hardware interupts. what that means in the most general sense is that you (as a driver) need to respond to that device and to deal with the condition that caused the interupt. but you don’t need to do it immedialty in a ‘stop the world’ kind of way, so you scheldule a DPC. i am sure that others can explain this better, but prehaps this is a start

3

any better answer?

4

Without explaining all of IRQL… the best answer I can concoct is:

When you’re running in your driver’s Interrupt Service Routine (ISR), you are (potentially) blocking not only additional interrupts from YOUR device, but also those from other devices. Therefore, you need to limit what you do in your ISR to only those things that are both absolutely essential and very quick. Anything else (such as emptying a device’s FIFO of data or scanning the in-memory data structure representing the state of your device’s transfers) needs to be done “later.”

Of course, you don’t want to wait TOO long to do these things “later” – This is where the DPC enters the picture, specifically, the DpcForIsr. This callback takes place with all (device) interrupt enabled so all device ISRs can run if they need to, but BEFORE returning back to process regular work scheduled by the Dispatcher… like running user threads.

In general, DPCs are kernel-mode (only) callbacks that occur at IRQL DISPATCH_LEVEL and in an arbitrary process and thread context.

I hope that helps… If you have further questions, feel free to ask.

Peter

5

that is true? you’re running at a high irql where you can’t do much (like use memory, etc). Dpcs are a way to say “I want to do this task when it becomes possible”. So when the irql becomes low enough, your dpc runs and the task you wanted to perform happens.

6

> @“Peter_Viscarola_(OSR)” said: > Without explaining all of IRQL… the best answer I can concoct is: > > When you’re running in your driver’s Interrupt Service Routine (ISR), you are (potentially) blocking not only additional interrupts from YOUR device, but also those from other devices. Therefore, you need to limit what you do in your ISR to only those things that are both absolutely essential and very quick. Anything else (such as emptying a device’s FIFO of data or scanning the in-memory data structure representing the state of your device’s transfers) needs to be done “later.” > > Of course, you don’t want to wait TOO long to do these things “later” – This is where the DPC enters the picture, specifically, the DpcForIsr. This callback takes place with all (device) interrupt enabled so all device ISRs can run if they need to, but BEFORE returning back to process regular work scheduled by the Dispatcher… like running user threads. > > In general, DPCs are kernel-mode (only) callbacks that occur at IRQL DISPATCH_LEVEL and in an arbitrary process and thread context. > > I hope that helps… If you have further questions, feel free to ask. > > Peter can you check my post?

7

can you check my post?

YOU need to learn patience. This is a public service offering valuable advice and is manned by volunteers. You demanded an answer 45 minutes after you posted your question. That is entirely unreasonable. You will get an answer when someone finds your post interesting enough to respond.

… where you can’t do much (like use memory etc.) …

The key is that you can’t take a lot of time. As a good neighbor, you shouldn’t WANT to take a lot of time, but there are now watchdogs that will fire a blue screen if an ISR takes too long.

… when the irql becomes low enough, your dpc runs …

Yes. When the IRQL drops, the scheduler runs through its list of pending DPCs and runs them all, in some order.

8

> @Tim_Roberts said: > (Quote) > YOU need to learn patience. This is a public service offering valuable advice and is manned by volunteers. You demanded an answer 45 minutes after you posted your question. That is entirely unreasonable. You will get an answer when someone finds your post interesting enough to respond. > > (Quote) > The key is that you can’t take a lot of time. As a good neighbor, you shouldn’t WANT to take a lot of time, but there are now watchdogs that will fire a blue screen if an ISR takes too long. > > (Quote) > Yes. When the IRQL drops, the scheduler runs through its list of pending DPCs and runs them all, in some order. I’m sorry I rushed. so dpc how can help isr? how it help to isr for run as son as possible?

9

Peter and I have both answered this question. When you are in an ISR, you are preventing that CPU from doing any other work. That’s not healthy for the overall system. To keep the system running well, you do as little as possible in your ISR, and complete the rest of your handling in a DPC.

10

Thanks man

11

can you show some example and source code?

12

can you show some example and source code?

Sure!

BOOLEAN
MyEvtInterruptIsr(
    IN WDFINTERRUPT Interrupt,
    IN ULONG  MessageID
    )
{
    BOOLEAN queueDpcSuccess;

    //
    // Save interrupt information for the
    // EvtInterruptDpc function.
    //
...
    //
    // Queue the EvtInterruptDpc function.
    //
    queueDpcSuccess = WdfInterruptQueueDpcForIsr(Interrupt);
...
}

Use_decl_annotations_
VOID
 MyInterruptDpc (
    WDFINTERRUPT  Interrupt,
    WDFOBJECT  AssociatedObject
    )
  {
  ...
  // 
  // Service your device here
  //
  ...
  }

How’s that? Right from the WDK docs.

Peter

13

Thanks man

14

You’re not trying very hard. EVERY sample driver that does interrupts uses DPCs, and many that don’t use them as well.