I suppose the idea was that the ‘list’ ought to be a feeder list for
your hardware, and that therefore a fifo was appropriate. Why not file a
bug report?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Sunday, July 08, 2001 10:49 PM
To: NT Developers Interest List
Subject: [ntdev] RE: [NTDEV] Queue Management …No sweat. You added to the conversation that might eventually
generate an answer. To me it’s a function that is needed, but
then maybe I’m the only one that needs to remove entries in
the middle of the list.Gary
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michael Jackson
Sent: Friday, July 06, 2001 10:39 AM
To: NT Developers Interest List
Subject: [ntdev] RE: [NTDEV] Queue Management …Gary:
Nope, I wasn’t.
I was saying that I was also puzzled that the set of list
functions was incomplete and at the time my guess as to why
they were incomplete was that they weren’t created for our
(the developer community outside of M$) use, but for some
task the OS developers needed done. They didn’t need to act
on entries in the middle of the list. Then the list
functions that were generated, were exposed for our use.This was just a guess. Sorry if I added to the confusion.
Michael J.
-----Original Message-----
From: Gary Little [mailto:xxxxx@Broadstor.com]
Sent: Thursday, July 05, 2001 1:24 PM
To: NT Developers Interest List
Subject: [ntdev] RE: [NTDEV] Queue Management …Michael,
I’m a bit confused … which my wife says is common at my age.
Are you implying that you, or a group you were associated
with, were responsible for the development of the
ExIntelocked… list functions?Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com-----Original Message-----
From: Michael Jackson [mailto:xxxxx@nmwco.com]
Sent: Thursday, July 05, 2001 12:41 PM
To: NT Developers Interest List
Subject: [ntdev] RE: [NTDEV] Queue Management …Gary:
When I saw this I assumed that this was just implemented for
a particular task and it didn’t involve operating on the
middle of the list. Nobody was given the task of creating a
“full” set of list operators.Are we having fun yet?
Michael S. Jackson
xxxxx@netmotionwireless.com-----Original Message-----
From: Gary Little [mailto:xxxxx@Broadstor.com]
Sent: Tuesday, July 03, 2001 10:50 AM
To: NT Developers Interest List
Subject: [ntdev] [NTDEV] Queue Management …In prior versions of the DDK, there has never been an
interlocked mid-queue management function. You can insert on
the tail or head using ExInterlockedInsertTail/HeadList, or
remove from the tail or head using
ExInterlockedRemoveTail/HeadList. However, the only way to
remove things from the middle of a queue was RemoveEntryList,
which is but one of those deadly macros.Why has there never been an ExInterlockedRemoveEntryList to
permit an orthogonal, and atomic, management of doubly linked
queues? For my own purposes I have written one using a
combination of inline assembly to clear and restore the
interrupt mask “pushfd/cli/…popfd”, and “lock bts” to
acquire a spin lock, and RemoveEntryList to manage the queue.
However, it would be nice if this were down in the HAL, or
kernel, to provide some platform independence and total
synchronized queue management.I posted this in the DDK Beta newsgroup for XP and received
the following reply from a Jamie Hunter at Microsoft:“Disabling and enabling the interrupts on NT code base is
bad! For starters, it will not be mutually exclusive in
multi-processor systems, so the behavior you expect isn’t
what you get, and this kind of thing makes drivers unstable
on multi-proc when working fine on single-proc.
ExInterlockedXXX APIs use processor instructions that are
guaranteed to be exclusive on a multi-processor system.
Depending on what you need to be exclusive with, you should
use spin-locks or KeSynchronizeExecution.”The fact that the ExInterlockedXXX functions use
“pushfd/cli/…popfd”, and “lock bts” to acquire a spin lock
tends to make the remainder of Jamie’s argument moot. I
simply think they need to add one more. Spin locks will not
solve my particular problem since the queue I am managing
must be accessed at IRQLs above DISPATCH_LEVEL. I cannot use
KeSynchronizeExecution because my design is such that queue
management is carried out in a layer where I do not have
access to the interrupt object. Without
ExInterlockedRemoveEntryList, management of that queue
between DISPATCH_LEVEL and DIRQL becomes a real problem.My question is, since interlocked functions exist for
Insert/Remove head/tail of a list, why not mid-queue
management as well?Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com
You are currently subscribed to ntdev as:
xxxxx@nmwco.com To unsubscribe send a blank email
to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
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@nmwco.com To unsubscribe send a blank email
to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@inland.net
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as:
xxxxx@hollistech.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