OS Question

Hi
This isnt strictly about a driver issue, but many driver coders may have
insights.

Basically we plan to user some of the Interlock functions (exchange,
exchange compare etc) as the basis for a simple fast lock (not in driver code
though).

However, we are also placing the integer values in pages that have had their
access set to Read Only. Currently when code attempts to write to such a page
we trap the exception, run a few checks and then update the page to have
Write access.

This is all standard stuff, BUT if we locate an integer in such a page AND
try to use an interlock exchnage kind of function on it, it raises an
interesting question.

The interlock operations are defined as being uniterruptible BUT if they are
in a ReadOnly page the operation WILL be interrupted (by the exception that
prevents writes to read only pages).

So would it work or not??

Any insights much appreciated.

PS: We are using XP, Vista, Server 2003 and 2008 both 32-bit and 64-bit.

Pavel
Sun May 11 10:48:13 CDT 2008

"Hugogleaves@hotmail.com>" <hugh<underbar> wrote in message
news:2A136AC4-76AD-4404-B0C1-67E6EC6BC15E@microsoft.com...
> Hi
> This isnt strictly about a driver issue, but many driver coders may have
> insights.
>
> Basically we plan to user some of the Interlock functions (exchange,
> exchange compare etc) as the basis for a simple fast lock (not in driver
> code
> though).
>
> However, we are also placing the integer values in pages that have had
> their
> access set to Read Only. Currently when code attempts to write to such a
> page
> we trap the exception, run a few checks and then update the page to have
> Write access.
>
> This is all standard stuff, BUT if we locate an integer in such a page AND
> try to use an interlock exchnage kind of function on it, it raises an
> interesting question.
>
> The interlock operations are defined as being uniterruptible BUT if they
> are
> in a ReadOnly page the operation WILL be interrupted (by the exception
> that
> prevents writes to read only pages).
>
> So would it work or not??
>
> Any insights much appreciated.
>
> PS: We are using XP, Vista, Server 2003 and 2008 both 32-bit and 64-bit.

Ok I'll try to answer this, as there's still no other replies.

Interlocked... functions do work with variables in pageable memory.
If these can be interrupted by paging operations, they can be
interrupted by other resumable exceptions as well;
so it will work exactly in same way.

Regards,
--PA

David
Sun May 11 12:50:56 CDT 2008

Here are the comments from InterlockedExchange which can be used to do
almost any interlocked operation.

InterlockedExchange should be used instead of ExInterlockedExchangeUlong,
because it is both faster and more efficient.

InterlockedExchange is implemented inline by the compiler when appropriate
and possible. It does not require a spin lock and can therefore be safely
used on pageable data.

A call to InterlockedExchange routine is atomic only with respect to other
InterlockedXxx calls.

Callers of InterlockedExchange can be running at any IRQL.

End comments.

If the data types are simple such as 32 or 64 bits depending upon the OS
target, this is a simple solution. The data item will reside within one
page unless you attempt some weird packing in structures. Creating the
source with code listing from the compiler can allow you to verify that one
instruction is used to update the data item. The interlocked operation will
be uninterruptable since the entire data item is updated at once. The fact
that the data is located in a read only page has no impact on the
uninterruptible-ness of the instruction as the instruction will not being
until the data can be written. Yes, another processor could come along
after the page has been changed to writable and it would get the operation
to complete before the thread that started the sequence can actually get
back to trying the interlocked operation. I would think long and hard about
just making pages read only when they must be written to with any frequency.

"Hugo gleaves@hotmail.com>" <hugh<underbar> wrote in message
news:2A136AC4-76AD-4404-B0C1-67E6EC6BC15E@microsoft.com...
> Hi
> This isnt strictly about a driver issue, but many driver coders may have
> insights.
>
> Basically we plan to user some of the Interlock functions (exchange,
> exchange compare etc) as the basis for a simple fast lock (not in driver
> code
> though).
>
> However, we are also placing the integer values in pages that have had
> their
> access set to Read Only. Currently when code attempts to write to such a
> page
> we trap the exception, run a few checks and then update the page to have
> Write access.
>
> This is all standard stuff, BUT if we locate an integer in such a page AND
> try to use an interlock exchnage kind of function on it, it raises an
> interesting question.
>
> The interlock operations are defined as being uniterruptible BUT if they
> are
> in a ReadOnly page the operation WILL be interrupted (by the exception
> that
> prevents writes to read only pages).
>
> So would it work or not??
>
> Any insights much appreciated.
>
> PS: We are using XP, Vista, Server 2003 and 2008 both 32-bit and 64-bit.
>

Alexander
Sun May 11 13:16:36 CDT 2008

An operation that involves memory modification will only start if the
destination is writeable, no matter if it's interlocked or not. An operation
won't be interrupted in between and then resumed.

I'm not sure why you want to modify page protection on the fly. If this is
for debugging, it's OK. If you base your design on this, it won't work
reliably.

"Hugo gleaves@hotmail.com>" <hugh<underbar> wrote in message
news:2A136AC4-76AD-4404-B0C1-67E6EC6BC15E@microsoft.com...
> Hi
> This isnt strictly about a driver issue, but many driver coders may have
> insights.
>
> Basically we plan to user some of the Interlock functions (exchange,
> exchange compare etc) as the basis for a simple fast lock (not in driver
> code
> though).
>
> However, we are also placing the integer values in pages that have had
> their
> access set to Read Only. Currently when code attempts to write to such a
> page
> we trap the exception, run a few checks and then update the page to have
> Write access.
>
> This is all standard stuff, BUT if we locate an integer in such a page AND
> try to use an interlock exchnage kind of function on it, it raises an
> interesting question.
>
> The interlock operations are defined as being uniterruptible BUT if they
> are
> in a ReadOnly page the operation WILL be interrupted (by the exception
> that
> prevents writes to read only pages).
>
> So would it work or not??
>
> Any insights much appreciated.
>
> PS: We are using XP, Vista, Server 2003 and 2008 both 32-bit and 64-bit.
>

gleaves
Sun May 11 13:22:00 CDT 2008



"David Craig" wrote:

> Here are the comments from InterlockedExchange which can be used to do
> almost any interlocked operation.
>
> InterlockedExchange should be used instead of ExInterlockedExchangeUlong,
> because it is both faster and more efficient.
>
> InterlockedExchange is implemented inline by the compiler when appropriate
> and possible. It does not require a spin lock and can therefore be safely
> used on pageable data.
>
> A call to InterlockedExchange routine is atomic only with respect to other
> InterlockedXxx calls.
>
> Callers of InterlockedExchange can be running at any IRQL.
>
> End comments.
>
> If the data types are simple such as 32 or 64 bits depending upon the OS
> target, this is a simple solution. The data item will reside within one
> page unless you attempt some weird packing in structures. Creating the
> source with code listing from the compiler can allow you to verify that one
> instruction is used to update the data item. The interlocked operation will
> be uninterruptable since the entire data item is updated at once. The fact
> that the data is located in a read only page has no impact on the
> uninterruptible-ness of the instruction as the instruction will not being
> until the data can be written. Yes, another processor could come along
> after the page has been changed to writable and it would get the operation
> to complete before the thread that started the sequence can actually get
> back to trying the interlocked operation. I would think long and hard about
> just making pages read only when they must be written to with any frequency.
>
> "Hugo gleaves@hotmail.com>" <hugh<underbar> wrote in message
> news:2A136AC4-76AD-4404-B0C1-67E6EC6BC15E@microsoft.com...
> > Hi
> > This isnt strictly about a driver issue, but many driver coders may have
> > insights.
> >
> > Basically we plan to user some of the Interlock functions (exchange,
> > exchange compare etc) as the basis for a simple fast lock (not in driver
> > code
> > though).
> >
> > However, we are also placing the integer values in pages that have had
> > their
> > access set to Read Only. Currently when code attempts to write to such a
> > page
> > we trap the exception, run a few checks and then update the page to have
> > Write access.
> >
> > This is all standard stuff, BUT if we locate an integer in such a page AND
> > try to use an interlock exchnage kind of function on it, it raises an
> > interesting question.
> >
> > The interlock operations are defined as being uniterruptible BUT if they
> > are
> > in a ReadOnly page the operation WILL be interrupted (by the exception
> > that
> > prevents writes to read only pages).
> >
> > So would it work or not??
> >
> > Any insights much appreciated.
> >
> > PS: We are using XP, Vista, Server 2003 and 2008 both 32-bit and 64-bit.
> >
>
>
> Firstly, thanks to Pavel A, and David Craig for responding, it is appreciated.

It seems from what you both say, that this will work in a predictable and
intuitive way; of course I will test the code heavily but I agree that it
should operate "as expected" under these circumstances.

In response to David's point, we do this to meet a design objective. We must
prevent errant user code from writing to pages that (may) contain system
structures. When a "user" calls one of our API functions all pages (in the
managed area) are ReadOnly (so that any errant code cannot trash system data)
but when API code attempts to update system data an exception is raised.

The exception handler runs and examines the details about what kind of data
was being written to and why, if this is determined to be valid we make the
page ReadWrite and record this fact.

Because API calls may be nested arbitrarily, we have logic to track the
"depth" of such calls, when the "outermost" API exits, this to ois detected
and the page (all impacted pages in fact) are reset to ReadOnly so that any
attempt by user (calling) code to write to such pages is trapped.

This works and means that NO erroneous code can ever inadvertently damage
system structures in shared memory.

Because our custom read/write spinlock code refers to fields in system
structures that are (therefore) in ReadOnly pages, we have do deal with this
question.

Anyway...I will now code up some formal test code and stress this out.

Thanks again to both of you for your comments.

Hugh

gleaves
Sun May 11 13:23:00 CDT 2008



"Alexander Grigoriev" wrote:

> An operation that involves memory modification will only start if the
> destination is writeable, no matter if it's interlocked or not. An operation
> won't be interrupted in between and then resumed.
>
> I'm not sure why you want to modify page protection on the fly. If this is
> for debugging, it's OK. If you base your design on this, it won't work
> reliably.
>
> "Hugo gleaves@hotmail.com>" <hugh<underbar> wrote in message
> news:2A136AC4-76AD-4404-B0C1-67E6EC6BC15E@microsoft.com...
> > Hi
> > This isnt strictly about a driver issue, but many driver coders may have
> > insights.
> >
> > Basically we plan to user some of the Interlock functions (exchange,
> > exchange compare etc) as the basis for a simple fast lock (not in driver
> > code
> > though).
> >
> > However, we are also placing the integer values in pages that have had
> > their
> > access set to Read Only. Currently when code attempts to write to such a
> > page
> > we trap the exception, run a few checks and then update the page to have
> > Write access.
> >
> > This is all standard stuff, BUT if we locate an integer in such a page AND
> > try to use an interlock exchnage kind of function on it, it raises an
> > interesting question.
> >
> > The interlock operations are defined as being uniterruptible BUT if they
> > are
> > in a ReadOnly page the operation WILL be interrupted (by the exception
> > that
> > prevents writes to read only pages).
> >
> > So would it work or not??
> >
> > Any insights much appreciated.
> >
> > PS: We are using XP, Vista, Server 2003 and 2008 both 32-bit and 64-bit.
> >
>
>
> I disagree, Microsoft actually published examples of doing this many years ago.

gleaves
Sun May 11 13:46:01 CDT 2008



"Alexander Grigoriev" wrote:

> An operation that involves memory modification will only start if the
> destination is writeable, no matter if it's interlocked or not. An operation
> won't be interrupted in between and then resumed.
>
> I'm not sure why you want to modify page protection on the fly. If this is
> for debugging, it's OK. If you base your design on this, it won't work
> reliably.
>
> "Hugo gleaves@hotmail.com>" <hugh<underbar> wrote in message
> news:2A136AC4-76AD-4404-B0C1-67E6EC6BC15E@microsoft.com...
> > Hi
> > This isnt strictly about a driver issue, but many driver coders may have
> > insights.
> >
> > Basically we plan to user some of the Interlock functions (exchange,
> > exchange compare etc) as the basis for a simple fast lock (not in driver
> > code
> > though).
> >
> > However, we are also placing the integer values in pages that have had
> > their
> > access set to Read Only. Currently when code attempts to write to such a
> > page
> > we trap the exception, run a few checks and then update the page to have
> > Write access.
> >
> > This is all standard stuff, BUT if we locate an integer in such a page AND
> > try to use an interlock exchnage kind of function on it, it raises an
> > interesting question.
> >
> > The interlock operations are defined as being uniterruptible BUT if they
> > are
> > in a ReadOnly page the operation WILL be interrupted (by the exception
> > that
> > prevents writes to read only pages).
> >
> > So would it work or not??
> >
> > Any insights much appreciated.
> >
> > PS: We are using XP, Vista, Server 2003 and 2008 both 32-bit and 64-bit.
> >
>
>
> This inst the example I was referring to, I cant find it just now, but here is one they published some years ago:

http://msdn.microsoft.com/en-us/library/ms810627.aspx

I want to stress that this mechanism we use is an option, if the
designer/coder that uses our API doesn't want the perf hit of doing this,
then they don't need to, it is just an option that they can use to afford
them the most protection, usually during dev/testing.

It is also worth stressing, that the access exception occurs only once (per
user API call) because once the page is set to ReadWrite inside the API lib,
it wont incur any more access exceptions, until after the API chain
ultimately returns to the caller, so it isn't as "bad" a hit as it may at
first seem.

Hugh

Maxim
Sun May 11 19:04:56 CDT 2008

> It is also worth stressing, that the access exception occurs only once (per
> user API call) because once the page is set to ReadWrite inside the API lib,
> it wont incur any more access exceptions, until after the API chain
> ultimately returns to the caller, so it isn't as "bad" a hit as it may at
> first seem.

This is not compatible with multithreading.

Non-multi-threaded API libraries modern days are just plain obsolete.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Alexander
Mon May 12 00:05:22 CDT 2008


"Hugo gleaves@hotmail.com>" <hugh<underbar> wrote in message
news:2279C281-3578-46A5-9577-D496F3A85D20@microsoft.com...
>> Firstly, thanks to Pavel A, and David Craig for responding, it is
>> appreciated.
>
> It seems from what you both say, that this will work in a predictable and
> intuitive way; of course I will test the code heavily but I agree that it
> should operate "as expected" under these circumstances.
>
> In response to David's point, we do this to meet a design objective. We
> must
> prevent errant user code from writing to pages that (may) contain system
> structures. When a "user" calls one of our API functions all pages (in the
> managed area) are ReadOnly (so that any errant code cannot trash system
> data)
> but when API code attempts to update system data an exception is raised.
>
> The exception handler runs and examines the details about what kind of
> data
> was being written to and why, if this is determined to be valid we make
> the
> page ReadWrite and record this fact.
>
> Because API calls may be nested arbitrarily, we have logic to track the
> "depth" of such calls, when the "outermost" API exits, this to ois
> detected
> and the page (all impacted pages in fact) are reset to ReadOnly so that
> any
> attempt by user (calling) code to write to such pages is trapped.
>
> This works and means that NO erroneous code can ever inadvertently damage
> system structures in shared memory.
>
> Because our custom read/write spinlock code refers to fields in system
> structures that are (therefore) in ReadOnly pages, we have do deal with
> this
> question.
>
> Anyway...I will now code up some formal test code and stress this out.
>
> Thanks again to both of you for your comments.
>
> Hugh
>

I'm afraid you've chosen a wrong solution for a wrong problem brought up by
wrong solution.

If I'm not mistaken, you share memory between user mode code and kernel
mode. I'd advise you to be fully aware that no matter how you try, you
cannot trust any data in that memory. Even if you change protection on the
fly, another thread running in that process might trash the data while it's
unprotected. I'm not sure why you want to share that memory then. Why not
just use kernel address space for that?

Trying to protect in-process data from rogue client of your DLL is an
exercise in futility. If you need your own trusted data, it should reside in
a different process, for example, a service.

The rule is simple. If you run in some context, you're at the mercy of other
code running in the same context. If you want otherwise, you need different
context (different process, or processor mode).

gleaves
Mon May 12 02:08:00 CDT 2008



"Maxim S. Shatskih" wrote:

> > It is also worth stressing, that the access exception occurs only once (per
> > user API call) because once the page is set to ReadWrite inside the API lib,
> > it wont incur any more access exceptions, until after the API chain
> > ultimately returns to the caller, so it isn't as "bad" a hit as it may at
> > first seem.
>
> This is not compatible with multithreading.
>
> Non-multi-threaded API libraries modern days are just plain obsolete.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>
Maxim;
Can you explain? what is not compatible with multithreading? If there is
anything that will prevent this from working reliably, do explain it will be
useful to know.

So far as page access rights go, these are (as you know) per-process, every
process has its own access rights to its VM pages (even shared pages have
per-process access rights).

The only area of uncertainty for me (I hope!) is the behavior of
InterlockedXXX on a datum in a ReadOnly page.

Thanks
Hugh

gleaves
Mon May 12 09:18:00 CDT 2008



"Pavel A." wrote:

> "Hugogleaves@hotmail.com>" <hugh<underbar> wrote in message
> news:2A136AC4-76AD-4404-B0C1-67E6EC6BC15E@microsoft.com...
> > Hi
> > This isnt strictly about a driver issue, but many driver coders may have
> > insights.
> >
> > Basically we plan to user some of the Interlock functions (exchange,
> > exchange compare etc) as the basis for a simple fast lock (not in driver
> > code
> > though).
> >
> > However, we are also placing the integer values in pages that have had
> > their
> > access set to Read Only. Currently when code attempts to write to such a
> > page
> > we trap the exception, run a few checks and then update the page to have
> > Write access.
> >
> > This is all standard stuff, BUT if we locate an integer in such a page AND
> > try to use an interlock exchnage kind of function on it, it raises an
> > interesting question.
> >
> > The interlock operations are defined as being uniterruptible BUT if they
> > are
> > in a ReadOnly page the operation WILL be interrupted (by the exception
> > that
> > prevents writes to read only pages).
> >
> > So would it work or not??
> >
> > Any insights much appreciated.
> >
> > PS: We are using XP, Vista, Server 2003 and 2008 both 32-bit and 64-bit.
>
> Ok I'll try to answer this, as there's still no other replies.
>
> Interlocked... functions do work with variables in pageable memory.
> If these can be interrupted by paging operations, they can be
> interrupted by other resumable exceptions as well;
> so it will work exactly in same way.
>
> Regards,
> --PA
>
>
>
Hi
I think your assessment is correct, I have created some test code and run
this as both a 32-bit app and a 64-bit app under Vista.

The code uses an interlocked LONG situated in a memory mapped page that has
its access set to Read only. A vectored exception handler runs whenever an
attempt is made to call InterlockedCompareExchange, the handler checks that
the exception is an access violation and that the attempted operation was a
write to the expected page and sets the page to ReadWrite and continues
execution.

The test code aquires the lock then does some random updated to the shared
page, sleeps for a while, checks that nothing has changed and then reverses
the updates, unlocks the lock and resets the page to ReadOnly.

Running several instances of this on a dual-core x64 box seems fine (if the
code sees any unexpected change to data it will report an error) even for
hours, so I think that the interlock behaves reliably even if interrupted.

Thx for reply.

Alexander
Mon May 12 09:31:14 CDT 2008


"Hugo gleaves@hotmail.com>" <hugh<underbar> wrote in message
news:AF8E146F-451D-4152-959F-D38571892327@microsoft.com...
>
>
>>
>>
> Hi
> I think your assessment is correct, I have created some test code and run
> this as both a 32-bit app and a 64-bit app under Vista.
>
> The code uses an interlocked LONG situated in a memory mapped page that
> has
> its access set to Read only. A vectored exception handler runs whenever an
> attempt is made to call InterlockedCompareExchange, the handler checks
> that
> the exception is an access violation and that the attempted operation was
> a
> write to the expected page and sets the page to ReadWrite and continues
> execution.
>
> The test code aquires the lock then does some random updated to the shared
> page, sleeps for a while, checks that nothing has changed and then
> reverses
> the updates, unlocks the lock and resets the page to ReadOnly.
>
> Running several instances of this on a dual-core x64 box seems fine (if
> the
> code sees any unexpected change to data it will report an error) even for
> hours, so I think that the interlock behaves reliably even if interrupted.
>
> Thx for reply.
>

Once again, this is an exercise in futility. Wrong and unnecessary solution
to a non-existing problem. It doesn't make sense to try to protect
in-process data from a mis-behaving client. If you want to protect shared
data, it should not be in the untrusted process; It needs to be in a
separate trusted process.

In your reply, the key word is "seems fine". So many times it's used in
context: "I implemented this kludge, it seems to work fine on my particular
machine, so it's good for production".

Maxim
Mon May 12 16:54:16 CDT 2008

> Can you explain? what is not compatible with multithreading? If there is

- 2 threads wants to write access the same data
- first gain the access
- second thread gains the access
- first thread does its work and returns
- on return, the data is marked back as read-only
- then second thread try to do work, and the data is read-only, a crash

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

m
Mon May 12 17:33:28 CDT 2008

More importantly, the 'protection' that this scheme offers does not exist
for a period of time when the API call is executing and so any 'rogue' code
can just write to the page then and it will be trashed.



Maxim's situation could be remedied by handling the second exception or
using locks on the APIs to prevent concurrent access to pages.


"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:e%23jB2tHtIHA.4912@TK2MSFTNGP03.phx.gbl...
>> Can you explain? what is not compatible with multithreading? If there is
>
> - 2 threads wants to write access the same data
> - first gain the access
> - second thread gains the access
> - first thread does its work and returns
> - on return, the data is marked back as read-only
> - then second thread try to do work, and the data is read-only, a crash
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>

David
Mon May 12 18:41:15 CDT 2008

Also the 'multithreading' can easily be fixed just by raising your IRQL to
dispatch level. In user mode you might be able to increase priority enough
to get control. However, this won't fix the multiprocessor problems. In
kernel mode only spinlocks can be used to control access to data or hardware
so that only one thread on one processor can have exclusive control.

"m" <m@b.c> wrote in message news:et5i0AItIHA.4544@TK2MSFTNGP04.phx.gbl...
> More importantly, the 'protection' that this scheme offers does not exist
> for a period of time when the API call is executing and so any 'rogue'
> code can just write to the page then and it will be trashed.
>
>
>
> Maxim's situation could be remedied by handling the second exception or
> using locks on the APIs to prevent concurrent access to pages.
>
>
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> news:e%23jB2tHtIHA.4912@TK2MSFTNGP03.phx.gbl...
>>> Can you explain? what is not compatible with multithreading? If there is
>>
>> - 2 threads wants to write access the same data
>> - first gain the access
>> - second thread gains the access
>> - first thread does its work and returns
>> - on return, the data is marked back as read-only
>> - then second thread try to do work, and the data is read-only, a crash
>>
>> --
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> maxim@storagecraft.com
>> http://www.storagecraft.com
>>
>
>

David
Mon May 12 19:14:25 CDT 2008

I should have said that in user mode you might be able to keep control in
one thread by going to realtime, but it is certain it will always work.
Programming for multiprocessor is always multithread safe, so do it in a way
it will be safe for SMP. Many current CPUs are SMP with multiple cores and
even the old hyperthreading simulates SMP but it was not quite as good as
having real multiple cores in a system. There are also tricks with
processor affinity in user mode that can help, but that type of code can be
fragile and hard to maintain - so why do it! Use a driver and spinlocks to
control access to low level resources. To protect data in user mode just
use semaphores, mutexes, and/or events as appropriate. Since this is not a
user mode code group, it is not really a good question for this newsgroup if
that is your target.

"David Craig" <drivers@nowhere.us> wrote in message
news:ubwXsmItIHA.1316@TK2MSFTNGP06.phx.gbl...
> Also the 'multithreading' can easily be fixed just by raising your IRQL to
> dispatch level. In user mode you might be able to increase priority
> enough to get control. However, this won't fix the multiprocessor
> problems. In kernel mode only spinlocks can be used to control access to
> data or hardware so that only one thread on one processor can have
> exclusive control.
>
> "m" <m@b.c> wrote in message news:et5i0AItIHA.4544@TK2MSFTNGP04.phx.gbl...
>> More importantly, the 'protection' that this scheme offers does not exist
>> for a period of time when the API call is executing and so any 'rogue'
>> code can just write to the page then and it will be trashed.
>>
>>
>>
>> Maxim's situation could be remedied by handling the second exception or
>> using locks on the APIs to prevent concurrent access to pages.
>>
>>
>> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
>> news:e%23jB2tHtIHA.4912@TK2MSFTNGP03.phx.gbl...
>>>> Can you explain? what is not compatible with multithreading? If there
>>>> is
>>>
>>> - 2 threads wants to write access the same data
>>> - first gain the access
>>> - second thread gains the access
>>> - first thread does its work and returns
>>> - on return, the data is marked back as read-only
>>> - then second thread try to do work, and the data is read-only, a crash
>>>
>>> --
>>> Maxim Shatskih, Windows DDK MVP
>>> StorageCraft Corporation
>>> maxim@storagecraft.com
>>> http://www.storagecraft.com
>>>
>>
>>
>
>

Pavel
Mon May 12 21:53:39 CDT 2008

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:#9zNCzDtIHA.4952@TK2MSFTNGP05.phx.gbl...
>
> Once again, this is an exercise in futility. Wrong and unnecessary
> solution to a non-existing problem. It doesn't make sense to try to
> protect

Why? As long as somebody pays for all this work and time, it's ok...

--PA

gleaves
Tue May 13 02:21:00 CDT 2008



"Maxim S. Shatskih" wrote:

> > Can you explain? what is not compatible with multithreading? If there is
>
> - 2 threads wants to write access the same data
> - first gain the access
> - second thread gains the access
> - first thread does its work and returns
> - on return, the data is marked back as read-only
> - then second thread try to do work, and the data is read-only, a crash
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>
Hi Maxim

The scenario you outline is correct, but the code isnt designed that way,
you have outlined an issue that a designer must address, but this is not an
incompatibility.

In reality the first thread doesnt reset page access to ReadOnly, the reset
only takes place if the returning thread is the last thread (this is tracked
in a count managed by a critical section).

All of this actually works, and was tested some time back (but the feature
has been dormant and unused for some time, but will be an officially
supported option for users of the API).

Thanks for outlining the issue though, it is a real issue and would be a
design need.

HUgh

gleaves
Tue May 13 02:28:01 CDT 2008



"m" wrote:

> More importantly, the 'protection' that this scheme offers does not exist
> for a period of time when the API call is executing and so any 'rogue' code
> can just write to the page then and it will be trashed.
>
>
>
> Maxim's situation could be remedied by handling the second exception or
> using locks on the APIs to prevent concurrent access to pages.
>
>
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> news:e%23jB2tHtIHA.4912@TK2MSFTNGP03.phx.gbl...
> >> Can you explain? what is not compatible with multithreading? If there is
> >
> > - 2 threads wants to write access the same data
> > - first gain the access
> > - second thread gains the access
> > - first thread does its work and returns
> > - on return, the data is marked back as read-only
> > - then second thread try to do work, and the data is read-only, a crash
> >
> > --
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > maxim@storagecraft.com
> > http://www.storagecraft.com
> >
>
>
>
Yes this is absolutely true, and documented for users of the API. There is a
window during which one thread has enabled write access (but only to the
pages it is touching) whilst another thread, not inside the API, erroneously
writes to one of the pages and causes damage.

This is sadly beyond our reach as a goal, but nevertheless the whole feature
is an option and mainly one that new users code will use during testing,
although there is a window I think the benefit afforded far outweighs this.

I think that in a future design, it might be possible to locate "some" of
the API inside some sort of kernel mode component but my knowledge of device
drivers (especially when used in such a "utility" fashion) is not very good.

Windows unfortunately provides no "out of the box" way for programmers to
write application code that can enjoy the same benefits as drivers (i.e. the
context mode change that allows drivers to access/update kernel structures or
pages allocated in one of the kernel heaps).

Hugh

gleaves
Tue May 13 02:51:01 CDT 2008



"David Craig" wrote:

> I should have said that in user mode you might be able to keep control in
> one thread by going to realtime, but it is certain it will always work.
> Programming for multiprocessor is always multithread safe, so do it in a way
> it will be safe for SMP. Many current CPUs are SMP with multiple cores and
> even the old hyperthreading simulates SMP but it was not quite as good as
> having real multiple cores in a system. There are also tricks with
> processor affinity in user mode that can help, but that type of code can be
> fragile and hard to maintain - so why do it! Use a driver and spinlocks to
> control access to low level resources. To protect data in user mode just
> use semaphores, mutexes, and/or events as appropriate. Since this is not a
> user mode code group, it is not really a good question for this newsgroup if
> that is your target.
>
> "David Craig" <drivers@nowhere.us> wrote in message
> news:ubwXsmItIHA.1316@TK2MSFTNGP06.phx.gbl...
> > Also the 'multithreading' can easily be fixed just by raising your IRQL to
> > dispatch level. In user mode you might be able to increase priority
> > enough to get control. However, this won't fix the multiprocessor
> > problems. In kernel mode only spinlocks can be used to control access to
> > data or hardware so that only one thread on one processor can have
> > exclusive control.
> >
> > "m" <m@b.c> wrote in message news:et5i0AItIHA.4544@TK2MSFTNGP04.phx.gbl...
> >> More importantly, the 'protection' that this scheme offers does not exist
> >> for a period of time when the API call is executing and so any 'rogue'
> >> code can just write to the page then and it will be trashed.
> >>
> >>
> >>
> >> Maxim's situation could be remedied by handling the second exception or
> >> using locks on the APIs to prevent concurrent access to pages.
> >>
> >>
> >> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> >> news:e%23jB2tHtIHA.4912@TK2MSFTNGP03.phx.gbl...
> >>>> Can you explain? what is not compatible with multithreading? If there
> >>>> is
> >>>
> >>> - 2 threads wants to write access the same data
> >>> - first gain the a