RE: [NTDEV] Queue Management ...

You may not have the interrupt object available. ExInterlocked… functions
provide a fairly generic means of synchronizing access to critical data
structures regardless of, and without knowing, what the highest IRQL is that
access given critical data. They do this by stacking the machine state,
clearing the interrupt mask and checking the spin lock for availability,
popping the machine state and doing it all again until the spin lock has
been seized. All of that is machine dependent, which is why it’s thought of
as a “NO NO”. ExInterlocked… functions really don’t care or need to know
what the interrupt or IRQL is.

Gary G. Little
Staff Engineer
Broadband Storage, Inc.
xxxxx@broadstor.com

-----Original Message-----
From: Maxim S. Shatskih [mailto:xxxxx@storagecraft.com]
Sent: Monday, July 16, 2001 1:13 PM
To: NT Developers Interest List
Subject: [ntdev] RE: [NTDEV] Queue Management …

Why not use explicit spinlock acquisition for list operations instead of
ExInterlockedxxx?

----- Original Message -----
From: “Gary Little”
To: “NT Developers Interest List”
Sent: Monday, July 16, 2001 10:46 PM
Subject: [ntdev] RE: [NTDEV] Queue Management …

> Michal,
>
> What I was hoping was to get a dialog started that might show a need for
> such functionality. However, with only two of us “discussing” it, I ain’t
a
> gonna hold my breath waiting for it to be added to the DDK. :slight_smile:
>
> I’m sure most of the “old timers” like you and I simply write such
> functionality and keep it in a tool box we use for projects we work on.
>
> Gary G. Little
> Staff Engineer
> Broadband Storage, Inc.
> xxxxx@broadstor.com
>
> -----Original Message-----
> From: Michal Vodicka [mailto:xxxxx@veridicom.cz.nospam]
> Sent: Monday, July 16, 2001 10:39 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: [NTDEV] Queue Management …
>
> Gary,
>
> this is what I’m complaining about. Somebody “wise” makes rules how
> something should be used from his narrow point of view and ignores all
other
> possibilities. Also ignores future evolution as you showed. The question
> isn’t “why?” but “why not?”. Double linked lists can be used for linking
any
> structures and random access is of course necessary. Limit them for
> (advanced) FIFOs only and force developers to write own list management is
> IMHO stupid. This API is apparently incomplete and I don’t understand the
> developer which can make something like this. Because of these “wise”
> persons who know better what we need only 10% of kernel and native APIs is
> documented, some native functions exported by NTDLL aren’t exported by
> kernel and so on.
>
> Well, stop complaining. This one is easy to fix although I fully agree
with
> you it would be nice to have it in HAL. Hopefully you explained them why
> pushfd / cli / popfd is necessary there :wink:
>
> Best regards,
>
> Michal Vodicka
> Veridicom
> (RKK - Skytale)
> [WWW: http://www.veridicom.com , http://www.skytale.com]
>
> > ----------
> > From: Gary G. Little[SMTP:xxxxx@inland.net]
> > Reply To: NT Developers Interest List
> > Sent: Sunday, July 15, 2001 7:19 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: [NTDEV] Queue Management …
> >
> > Michael,
> >
> > Actually in the conversations that I have had off line with the folks at
> > Microsoft about this, I can understand why this function was omitted. No
> > one
> > thought they needed it since the general thinking was that the functions
> > provided full filled the perceived need as to how this “queuing” would
be
> > used. If you have the view that these functions are, or will be used,
only
> > as FIFO’s into a piece of hardware, then you do not need to give the
> > capability of unplugging an item from the middle of a queue and the
> > hanging
> > it on the hardware. Indeed, on the hardware end of things, I have bent
> > over
> > backwards to kiss my gluteus maximus to make sure that everything
> > funneling
> > into the hardware was first in first out. Why? Because if the user comes
> > back to me and says “I got these out of order …” I can then say, “Ok,
> > then
> > why did you send them out order?”
> >
> > That, however, was in the beginning … today, we have device stacks and
> > nodes all over the place, with possibly several drivers blessing a queue
> > before it gets plugged into the PDO for transfer to the hardware, and it
> > is
> > quite possible that one of those drivers will need to POP an item from
the
> > middle of that queue. In other words, when the queue is going to a
framis,
> > then I need to open the framis aperture, but if I’m going to a widget,
> > then
> > a widget doesn’t have an aperture and I’ll only confuse the widget if I
> > give
> > it that item. Sure, the PDO can say “Widget or framis?”, but that adds
> > complexity that can more easily be handled in an upper layer.
> >
> > In other words, the need for ExInterlockedRemoveEntryList has evolved.
> > Those
> > of us that need it, write it. It would, however, be nice if it were
added
> > to
> > the HAL, so that it could be used across all possible hardware
platforms.
> >
> > Gary
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
> > Sent: Friday, July 13, 2001 6:50 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: [NTDEV] Queue Management …
> >
> > > ----------
> > > From: Eliyas Yakub[SMTP:xxxxx@microsoft.com]
> > > Reply To: NT Developers Interest List
> > > Sent: Monday, July 09, 2001 7:44 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] RE: [NTDEV] Queue Management …
> > >
> > > >“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.
> > >
> > Well, this is the way of thinking typical for DDKs :frowning: Somebody at
> > Microsoft makes the decision which is sufficient for DDK examples but
bad
> > for the real world. The results are incomplete headers, documentation
and
> > API as in this case. Yes, I also missed ExInterlockedRemoveEntryList and
> > implemented it myself.
> >
> > Best regards,
> >
> > Michal Vodicka
> > Veridicom
> > (RKK - Skytale)
> > [WWW: http://www.veridicom.com , http://www.skytale.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@rkk.cz
> > 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@storagecraft.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: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com