Hi,
Internally, my driver is using some configuration data (about 100 Kb). This
configuration data can be accessed via a global variable that points to the
beginning of the configuration data. The data is accessed when IRPs do
“down”, in completion routines and in worker threads.
The configuration data can be dynamically updated via a user-mode program
that issues a IOCTL.
What is the best way to make sure that during such dynamic updates, no
other place in my driver will access the config data ?
Please help.
Bartjan.
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
What I forgot to tell you is that the completion routines and worker
threads will do file I/O. So that probably makes using synchronisation
objects somewhat more difficult.
Bartjan.
At 03:24 PM 5/4/2001 +0200, File Systems Developers wrote:
Internally, my driver is using some configuration data (about 100 Kb).
This configuration data can be accessed via a global variable that points
to the beginning of the configuration data. The data is accessed when IRPs
do “down”, in completion routines and in worker threads.
The configuration data can be dynamically updated via a user-mode program
that issues a IOCTL.
What is the best way to make sure that during such dynamic updates, no
other place in my driver will access the config data ?
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Hi there!
If your code or task with file I/O can tolerate being run at DISPATCH_LEVEL,
use spinlocks. Otherwise, you may implement your own “spinlock” - using
InterlockedCompareExchange. Will you do file I/O during locked access to this
configuration block? If not, use a global spinlock. If yes, use a global
self-made “spinlock”.
Greetings,
Alex
What I forgot to tell you is that the completion routines and worker
threads will do file I/O. So that probably makes using synchronisation
objects somewhat more difficult.
Bartjan.
At 03:24 PM 5/4/2001 +0200, File Systems Developers wrote:
>Internally, my driver is using some configuration data (about 100 Kb).
>This configuration data can be accessed via a global variable that points
>to the beginning of the configuration data. The data is accessed when
IRPs
>do “down”, in completion routines and in worker threads.
>
>The configuration data can be dynamically updated via a user-mode program
>that issues a IOCTL.
>
>What is the best way to make sure that during such dynamic updates, no
>other place in my driver will access the config data ?
You are currently subscribed to ntfsd as: xxxxx@gmx.net
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
–
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Thanks Alexander. Could you please explain what you mean by using a
“self-made spinlock”. Do you mean a simple flag telling “I’m doing
so-and-so right now” ?
–
Bartjan.
At 04:55 PM 5/4/2001 +0200, Alexander Platonow wrote:
Hi there!
If your code or task with file I/O can tolerate being run at DISPATCH_LEVEL,
use spinlocks. Otherwise, you may implement your own “spinlock” - using
InterlockedCompareExchange. Will you do file I/O during locked access to this
configuration block? If not, use a global spinlock. If yes, use a global
self-made “spinlock”.
Greetings,
Alex
> What I forgot to tell you is that the completion routines and worker
> threads will do file I/O. So that probably makes using synchronisation
> objects somewhat more difficult.
>
> Bartjan.
>
> At 03:24 PM 5/4/2001 +0200, File Systems Developers wrote:
> >Internally, my driver is using some configuration data (about 100 Kb).
> >This configuration data can be accessed via a global variable that points
>
> >to the beginning of the configuration data. The data is accessed when
> IRPs
> >do “down”, in completion routines and in worker threads.
> >
> >The configuration data can be dynamically updated via a user-mode program
>
> >that issues a IOCTL.
> >
> >What is the best way to make sure that during such dynamic updates, no
> >other place in my driver will access the config data ?
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@gmx.net
> To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>
–
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
You are currently subscribed to ntfsd as: xxxxx@zeelandnet.nl
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com