Ben Geib wrote:
That's not a sensible question. The DPC object IS "the DPC".

Yes, you can create any number of DPC objects that point to the same DPC
routine, but that is probably not the right way to solve your problem.
What happens when you run out? How does the ISR know which one to queue
next? How will you deal with the fact that the same DPC object can get
queued again on a different CPU as soon as it's dequeued on this CPU,
with the result that two different instances of the DPC routine will
potentially be running simultaneously with the same DPC object pointer
as an argument?

You could use an interlocked list (accessible at any IRQL): the ISR
takes items off a free list and stuffs them with information about an
interrupt before queuing them on a "to do" list; the DPC routine takes
items off the "to do" list, does something, and puts them back on the
free list.

You could use InterlockedOr in the ISR to set flag bits. Each time the
DPC routine runs, it does an InterlockedExchange with zero and then does
stuff for each of the 1-bits it sees.

You could have the ISR inhibit the device from further interrupts and
have the DPC routine remove the inhibition at the end.

Now, if what you're really trying to do is to have multiple instances of
a DPC routine running simultaneously on different CPU's to service
different ports, then by all means create a separate DPC object for each
port. You might even want to force the CPU affinity of the DPC objects
so as to distribute the work.

--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Check out our schedule at http://www.oneysoft.com