Hi every1:
may I ask
why StartIo run in DPC level ?
Does it possible that StartIo is excuted concurrently in 2 different CPUs when there’s multiple processors ?
Best Regards,
Alan
On Tue, 2004-06-15 at 20:59, Alan Kung wrote:
why StartIo run in DPC level ?
That’s the way it’s designed. The StartIo model assumes you’re calling
IoStartNextPacket() from a DPC routine anyway, so you’re likely to
already be at dispatch level (the exception being if you’re queuing a
packet from a dispatch routine using IoStartPacket()).
Does it possible that StartIo is excuted concurrently in 2 different
CPUs when there’s multiple processors ?
No, it’s managed by a device queue, so it will be serialized,
driver-wide. Study KeInsertDeviceQueue and KeRemoveDeviceQueue for more
details on this synchronization. You can break this model if you do
dumb things, but if you stick to having only your dispatch routines call
IoStartPacket() and only your DPC routine call IoStartNextPacket(),
you’ll be OK.
For what it’s worth, it’s often (always?) better to use the cancel-safe
queue library (IoCsqXxx and friends), as it doesn’t hit the global
cancel spinlock, which is a pretty hot lock and consequently a perf
bottelneck.
To the MS folks, I noticed a minor doc bug while I was checking
something related to this post - IoReleaseCancelSpinLock in the .net ddk
has its arg documented as a pointer to an IRQL, but it’s prototyped as
just taking an IRQL.
-sd