Hello,
Can i use kernel function InsertTailList instead use “ExInterlockedInsertTailList” function ,
with using resource function "ExAcquireResourceExclusiveLite and ExReleaseResourceLite ???
It it good ?
Thank.
Hello,
Can i use kernel function InsertTailList instead use “ExInterlockedInsertTailList” function ,
with using resource function "ExAcquireResourceExclusiveLite and ExReleaseResourceLite ???
It it good ?
Thank.
xxxxx@sivaller.no-ip.org wrote:
Can i use kernel function InsertTailList instead use “ExInterlockedInsertTailList” function ,
with using resource function "ExAcquireResourceExclusiveLite and ExReleaseResourceLite ???It it good ?
I’m not exactly sure what you’re asking. You can certainly use the
non-interlocked version of InsertTailList, as long as you protect it
with your own lock.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> xxxxx@sivaller.no-ip.org wrote:
> Can i use kernel function InsertTailList instead use
> “ExInterlockedInsertTailList” function ,
> with using resource function "ExAcquireResourceExclusiveLite and
> ExReleaseResourceLite ???
>
> It it good ?I’m not exactly sure what you’re asking. You can certainly use the
non-interlocked version of InsertTailList, as long as you protect it
with your own lock.
As long as you protect access, the exact protection doesn’t matter in
terms of correctness. However, if the only thing you are protecting is
the InsertTailList, ten using a rsource would be silly, because it would
be massive overhead. Taht is, if your code is.
ExAcquireResourceExlusiveLite(…)
InsertTailList(…);
ExReleaseResourceLite(…);
then it makes no sense at all. If you are doing a lot of other things
inside that protected area, then yes, InsertTailList will be protected.
But some things you need to keep in mind:
(1) you may not use any of the ExInterlocked operations on the list, ever.
The spin lock is used in odd ways that are not compatible with ordinary
spin locks
(2) Every access to the list MUST use the ERESOURCE for protection, even
checking IsListEmpty(…)
(3) No access may use any other synchronization mechanism
The only issue from the non-Inerlocked operations is that you must not be
accessing the list from more than one thread. Any synchronization
mechanism that accomplishes this guarantees correctness, but you must use
exactly the same lock object to protect access; you can’t mix mechanisms.
joe
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer