Re: Mutual Exclusion for shared Buffer b/n User and Kernel
- From: "Don Burn" <burn@xxxxxxxxxxxxxxxx>
- Date: Mon, 17 Apr 2006 13:44:34 -0400
Comments inline
"anton bassov" <xxx@xxxxxxx> wrote in message
news:e6175f5dc1d6472ca28f493e403cae0a@xxxxxxxxxxxxxx
Hi Don
You said that using events is the only scheme that is worth
consideration -
according to you,polling is just a waste of CPU time.
We have "clashed" on quite a few occasions when it comes to
"unsupported" stuff, and I even said that, apparently, you had had some
unpleasant experience with it. Now I see the possible explanation.
I would say that, as a general rule, the less the system knows about your
"unsupported" tricks, the better it is for you. Therefore, it is always a
good idea to make the system believe that nothing is happening.
Well, first I recomended against sharing the buffer period. Sharing an
event between the kernel and user space is documented by Microsoft and there
have be Microsoft provided samples for 10 years so I believe they will be
hard pressed to eliminate it.
Look at how I presented the polling option
while(1)
{
KeDelayExecutionThread();
...check the state of some variable that is available to user mode..
}
In the above example, there is no synchronization between driver and
application whatsoever, at least as far as the system is concerned. We do
waste few CPU cycles here, I don't argue about it. However, overhead is
not
that high, and, as far as I understand, performance is not the primary
concern here - otherwise, the bloke would not even think about making his
driver wait for user-mode application, would he??? Therefore, I would say
that,in terms of performance, the above approach is not much worse than
using events
Of course the above as you point out will have poor performance, and the
only reason anyone would share a buffer is for performance. If you are
doing it for an approach with slow performance then you are ignoring the
Windows model, that is just poor design. With the design you gain nothing,
but add complexity including making very hard for the next poor developer
who has to pick it up.
The ULTIMATE advantage of such approach is that, unlike the scheme that
relies upon events, our code cannot be broken by any system update.
Imagine
what happens if some future release prohibits using
ObReferenceObjectByHandle()on handles that have been opened by user-mode
code (currently the system just disallows to use these handles directly,
but,
in order to close the loophole, it may prohibit passing them to
ObReferenceObjectByHandle()as well).
However, it cannot do anything about KeDelayExecutionThread()and checking
the variable.
To summarize, when you try some hack, don't tell the system about it - it
increases reliability of your code dramatically
The claim of not telling the system, is very similar to some developers who
roll their own for things like spin locks and other kernel functions. Most
of the time they do not get the performance or compatibility they wanted,
but waste a lot of time and memory. One client I helped had such a driver,
it was 60000 lines of crap that dropped to below 8000 lines once we started
using the kernel calls, with WDF it would have shrunk significanly again.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
.
- Follow-Ups:
- Re: Mutual Exclusion for shared Buffer b/n User and Kernel
- From: anton bassov
- Re: Mutual Exclusion for shared Buffer b/n User and Kernel
- References:
- Re: Mutual Exclusion for shared Buffer b/n User and Kernel
- From: Don Burn
- Re: Mutual Exclusion for shared Buffer b/n User and Kernel
- From: anton bassov
- Re: Mutual Exclusion for shared Buffer b/n User and Kernel
- Prev by Date: Re: Mutual Exclusion for shared Buffer b/n User and Kernel
- Next by Date: Re: Re:Mutual Exclusion for shared Buffer b/n User and Kernel
- Previous by thread: Re: Mutual Exclusion for shared Buffer b/n User and Kernel
- Next by thread: Re: Mutual Exclusion for shared Buffer b/n User and Kernel
- Index(es):
Relevant Pages
|
