Elias,
Sorry, I must of have gotten your response lost in the bifocal crack of my
glasses. 
I check the Whistler DDK newsgroup daily and the only reply I
saw was from Jamey.
You can traverse such a queue with anonymity. All you need to do is use a
spin lock to make sure your synced in your DPC routine. However, to remove
an item from that queue you MUST sync to the highest IRQL that will be
accessing that queue, and you may not have the interrupt object pointer
available. In my case, my ISR is in a lower driver that inserts items onto
the queue in question using ExInterlockedInsertTailList. If all I had to do
was to pop the next item available in my upper driver, that does not have
the interrupt object, then no problem, just call
ExInterlockedRemoveHeadList. However, the upper layer driver must traverse
that shared queue, matching user IRPs with the holding queue, complete those
IRPs as needed when a match is found, and then manage the holding and free
queues shared with the lower driver.
The scenario is …
ISR
Ok the remote fella wants me to do something, but the local fella hasn’t
told me how to handle this, so remove an item from the free queue, save the
volatile data and hang it on the holding queue.
DPC
Ok, I have this item in the ISR holding queue. Does the current request from
the user match this item? No, then go on to the next item in the holding
queue. Yes, then remove it from the holding queue and return it to the free
queue (both shared at ISR), and complete the users IRP with the item I
found.
The current functions work great as a FIFO, but do not fill the need in an
on demand scenario. I solved my problem by writing
ExInterlockedRemoveEntryList, and patterning it after the interlocked
remove/insert head/tail functions.
Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com
-----Original Message-----
From: Eliyas Yakub [mailto:xxxxx@microsoft.com]
Sent: Monday, July 09, 2001 10:45 AM
To: NT Developers Interest List
Subject: [ntdev] RE: [NTDEV] Queue Management …
Gary,
I responded to this question in the newsgroup. Anyway, here again for
the benefit of the people on this forum:
“Gary G. Little” wrote in message:
>Why has there never been an ExInterlockedRemoveEntryList to permit an
>orthagonal, and atomic, management of doubly linked queues?
The question boils down to, where did you get the pointer to the object
you
want to remove? If you had to traverse the list to find it then you
already had to have the list locked in which case, when you find it you
can
just use RemoveEntryList. You can certainly come up with cases of
having
an arbitrary pointer to an object but the normal case is you had to get
that
pointer from somewhere. Anyway, that’s why.
-Eliyas
—
You are currently subscribed to ntdev as: xxxxx@broadstor.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