Use STL ? 
Alberto.
-----Original Message-----
From: Barila, Phil [mailto:xxxxx@intel.com]
Sent: Wednesday, July 25, 2001 8:13 PM
To: NT Developers Interest List
Subject: [ntdev] Re: [NTDEV] Queue Management
OK, Iāll display my ignorance for all to see. I donāt deal with interlocked
lists in my environment, so I donāt have a lot of reason to think about
them. But I am curious to know how you can be bullet-proof sure that you
have a valid pointer to an arbitrary element in the list without having
traversed it.
Phil
-----Original Message-----
From: Gary Little [mailto:xxxxx@Broadstor.com]
Sent: Wednesday, July 25, 2001 5:10 PM
To: NT Developers Interest List
Subject: [ntdev] Re: [NTDEV] Queue Management
Thanks Peter. I expected that ā¦ it parallels the conversation I had with
Elyas. Most of us out here in the trenches can blow holes in every argument
presented ā¦ but you aināt them and itās them we need to convince.
So, 'nuff said. Iāll have to continue to āstep out side the boxā to do what
I have to do.
Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com
-----Original Message-----
From: Peter Viscarola [mailto:xxxxx@osr.com]
Sent: Wednesday, July 25, 2001 3:52 PM
To: NT Developers Interest List
Subject: [ntdev] Re: [NTDEV] Queue Management
āGary Littleā wrote in message news:xxxxx@ntdevā¦
> to know there is a big enough presence in the development community that
> would use such an extension.
>
OK, guys. It took a while (mostly it took a while for me to read this) but
I got an answer on this from āMicrosoftā:
It turns out that this addition has been discussed and considered in some
depth in the past. The consensus is that ExInterlockedRemoveEntryList() can
only be used correctly in a very small number of situations. There just
arenāt that many cases when you know for sure that the entry is going to be
on the list, without actually traversing the list. For those few cases when
you CAN be sure, itās no more overhead to lock the list, remove the entry
with RemoveEntryList(), and then drop the lock. Which is what this function
would do in any case.
Balancing this is the fact that this function could very easily be subject
to unintentional misuse. I think youāll agree that few enough people think
through the impact of simultaneous access to their data structures as it is.
Having an ExInterlockedRemoveEntryList() seems like an invitation for people
to shoot themselves in the foot. No, not everybody. But this function does
seem to have a greater propensity for potential misuse than most.
Soā¦ weāve asked, and weāve gotten an anwer. Microsoft isnāt going to add
ExInterlockedRemoveEntryList to the kernel. You can disagree with the
result, or the reasoning given, if you like. But at least you know that
somebody asked, and the relevant developers at Microsoft were sufficiently
interested to provide a detailed response, the essence of which I have now
passed along to you.
I hope that helps,
Peter
ā
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: xxxxx@intel.com
To unsubscribe send a blank email to leave-ntdev-$subst(āRecip.MemberIDCharā)@lists.osr.com
ā
You are currently subscribed to ntdev as: xxxxx@compuware.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