Gary:
Seems to me like you ought to call KeSynchronizeExecution from DISPATCH_LEVEL
to access the queue instead of depending on the spinlock of
ExInterlockedXxx functions.
That’s how the interrupt would get delayed. The spinlock is just a
spinlock. It burns cycles but does not let
your DISPATCH_LEVEL routine get into the action.
George
At 12:07 PM 3/21/01 -0800, you wrote:
Windows 2000
128 Meg
Dual or Uni-processorI have a queue that is accessed at both DISPATCH_LEVEL and at DIRQL. The
queue is built with a lock for use by the ExInterlockedXxxx functions.
Accessing this queue at either level appears to work on a dual processor,
but the driver is hanging on a customers uni-processor system, and I think
this is the culprit.On a dual processor, one processor can be at DIRQL and looping waiting on
the queue lock, while the other processor, which has the lock, finishes up
its queue activity and then releases the lock. However, on a uni-processor,
can an interrupt arbitrarily raise IRQ to DIRQL and then attempt to acquire
the spinlock before it is released? If ExInterlockedXxxx is atomic, which I
believe it is, then the interrupt should be delayed until ExInterlockedXxxx
completes.Gary
You are currently subscribed to ntdev as: xxxxx@brd.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com