InterlockedXxx question

According to the DDK documentation, InterlockedXxx is atomic with
respect to other InterlockedXxx. Does that mean, in a hypothetical
scenario, where my driver is synchronizing read/write to a memory
location with some third party driver(s) and those drivers do not use
InterlockedXxx, calling this API is futile? Will spin lock save the day?
I guess not. So, what are my options in a described scenario?

Robert Milharcic

You have described a problem with no good solution. The bad solution is to
‘corral all the processors’ and execute the write at raised IRQL > either
DISPATCH_LEVEL or your other driver’s DIRQL on one of the corralled
processors. But you probably have a fundamental design flaw if your design
requires this level of idiocy. Perhaps you might want to share how you got
yourself into this predicament and then perhaps people on this list can find
a better way to solve your problem.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Robert M.
Sent: Tuesday, April 04, 2006 6:27 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] InterlockedXxx question

According to the DDK documentation, InterlockedXxx is atomic
with respect to other InterlockedXxx. Does that mean, in a
hypothetical scenario, where my driver is synchronizing
read/write to a memory location with some third party
driver(s) and those drivers do not use InterlockedXxx,
calling this API is futile? Will spin lock save the day?
I guess not. So, what are my options in a described scenario?

Robert Milharcic


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

Mark Roddy wrote:

You have described a problem with no good solution. The bad solution is to
‘corral all the processors’ and execute the write at raised IRQL > either
DISPATCH_LEVEL or your other driver’s DIRQL on one of the corralled
processors.

The problem here is that my other driver is not mine. DIRQL for other
driver is unknown.

But you probably have a fundamental design flaw if your design
requires this level of idiocy. Perhaps you might want to share how you got
yourself into this predicament and then perhaps people on this list can find
a better way to solve your problem.

Well, I am going through a white paper I found at WHDC. The paper I read
does not cover previously described situation. The situation I posted is
a construct, I simply invented it. The point I’m trying to make is that
situations like this can be unavoidable in some rare situations … yet
you telling me there is no good solution…

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Robert M.
> Sent: Tuesday, April 04, 2006 6:27 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] InterlockedXxx question
>
>
> According to the DDK documentation, InterlockedXxx is atomic
> with respect to other InterlockedXxx. Does that mean, in a
> hypothetical scenario, where my driver is synchronizing
> read/write to a memory location with some third party
> driver(s) and those drivers do not use InterlockedXxx,
> calling this API is futile? Will spin lock save the day?
> I guess not. So, what are my options in a described scenario?
>
> Robert Milharcic
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
>
>


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Unfortunately trying to modify the data of another driver without its
explicit support is a crash waiting to happen. Forget about this, either
license the source to the other driver, get documentation enough to replace
the other driver, or rethink your complete approach.


Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Robert M.” wrote in message news:xxxxx@ntdev…
> The problem here is that my other driver is not mine. DIRQL for other
> driver is unknown.
>

Correct - there is no good solution that allows you to arbitrarily and
atomically change the data of another driver without introducing any
synchronization in the other driver.

In this case you’d need to go back and rethink your design and see what
you can change to make it workable.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Robert M.
Sent: Tuesday, April 04, 2006 7:08 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] InterlockedXxx question

Mark Roddy wrote:

You have described a problem with no good solution. The bad solution
is to ‘corral all the processors’ and execute the write at raised IRQL

> either DISPATCH_LEVEL or your other driver’s DIRQL on one of the
corralled processors.

The problem here is that my other driver is not mine. DIRQL for other
driver is unknown.

But you probably have a fundamental design flaw if your design
requires this level of idiocy. Perhaps you might want to share how you

got yourself into this predicament and then perhaps people on this
list can find a better way to solve your problem.

Well, I am going through a white paper I found at WHDC. The paper I read
does not cover previously described situation. The situation I posted is
a construct, I simply invented it. The point I’m trying to make is that
situations like this can be unavoidable in some rare situations … yet
you telling me there is no good solution…

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032 www.hollistech.com

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Robert M.
> Sent: Tuesday, April 04, 2006 6:27 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] InterlockedXxx question
>
>
> According to the DDK documentation, InterlockedXxx is atomic with
> respect to other InterlockedXxx. Does that mean, in a hypothetical
> scenario, where my driver is synchronizing read/write to a memory
> location with some third party
> driver(s) and those drivers do not use InterlockedXxx, calling this
> API is futile? Will spin lock save the day?
> I guess not. So, what are my options in a described scenario?
>
> Robert Milharcic
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer