In the docs for KeInsertQueueDpc I see “Note that a given DPC object and
the function it represents can each be queued for execution only once at
any given moment.”. Does that refer to per-processor dpc queue or to the
system as a whole?
And even if the Dpc can only ever be queued for execution once at any
given time system-wide, it can still be executing on more than one CPU
at once right? Eg this could happen:
. KeInsertQueueDpc on CPU0
. KeInsertQueueDpc on CPU1 (but not queued because already queued on
CPU0 [1])
. Start running on CPU0
. KeInsertQueueDpc on CPU0 (but don’t start running because already
executing [2])
. Finish on CPU0
. Start running on CPU0 (because already queued)
. KeInsertQueueDpc on CPU1 (yes because not queued anywhere - running
doesn’t count [3])
. Start running on CPU1 (yes because the fact that it’s running on CPU0
doesn’t count [4])
. Finish on CPU0
. Finish on CPU1
Are my statements 1-4 correct?
Another whatif… If the Dpc is queued on CPU0’s queue and then
KeInsertQueueDpc is called on CPU1, does the Dpc change to CPU1 or stay
queued on CPU0?
Thanks
James
> Does that refer to per-processor dpc queue or to the system as a whole?
Just look at KDPC declaration in ntddk.h, and you will see that is just does not have a chance to be queued to multiple CPUs at once -such feature would require multiple pointers to per-processor queues that KDPC does not have…
And even if the Dpc can only ever be queued for execution once at any given time system-wide,
it can still be executing on more than one CPU at ,once right?
This is true…
Once DPC gets dequeued, it can be queued again. Therefore, it may happen that an instance of DPC routine starts running on CPU Y before the one running on CPU X returns control. This is what makes Windows DPCs different from Linux tasklets that cannot run concurrently…
Anton Bassov
>
> Does that refer to per-processor dpc queue or to the system as a
whole?
Just look at KDPC declaration in ntddk.h, and you will see that is
just does
not have a chance to be queued to multiple CPUs at once -such feature
would
require multiple pointers to per-processor queues that KDPC does not
have…
Thanks Anton. I didn’t think of looking there.
> And even if the Dpc can only ever be queued for execution once at
any given
time system-wide,
> it can still be executing on more than one CPU at ,once right?
This is true…
Once DPC gets dequeued, it can be queued again. Therefore, it may
happen that
an instance of DPC routine starts running on CPU Y before the one
running on
CPU X returns control. This is what makes Windows DPCs different from
Linux
tasklets that cannot run concurrently…
Thanks for confirming.
James
> Thanks Anton. I didn’t think of looking there.
In fact, you should attribute all credit for this to Mr.Cattley. I made a similar erroneous statement about DPC some time ago, to which Mr.Cattley said “Anton, look at KDPC declaration - it just does not have enough pointers to make it work the way you say”. Therefore, when I saw your question I immediately recalled that discussion…
Anton Bassov
>Are my statements 1-4 correct?
Yes.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com