Exinterlocked…List don’t screw with IRQL…they clear the interrupt flag
temporarily instead. While inside an Exinterlocked…List function, an
interrupt Cannot arbitrarily raise IRQ to DIRQL and then attempt to acquire
the spinlock before it is released
One guess for the cause of the hang is that you’re also playing with that
spin lock somewhere outside of the protected realm of Exinterlocked…List.
-----Original Message-----
From: Gary G. Little [mailto:xxxxx@inland.net]
Sent: Wednesday, March 21, 2001 2:07 PM
To: NT Developers Interest List
Subject: [ntdev] [NTDev] Using ExInterlockedInsertTailList in uni- and
multi-processor systems …
Windows 2000
128 Meg
Dual or Uni-processor
I 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@timesn.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