[Info-vax] Volatile, was: Re: yet another sys$qiow question
VAXman- at SendSpamHere.ORG
VAXman- at SendSpamHere.ORG
Fri Aug 21 09:36:48 EDT 2015
In article <55d64a0c$0$29676$c3e8da3$dbd57e7 at news.astraweb.com>, JF Mezei <jfmezei.spamnot at vaxination.ca> writes:
>Question for Mr VAXman:
>
>Since you live/eat/sleep/dream in kernel mode, do you still have to
Let's qualify that as inner mode; I hack in all modes.
>worry about something modifying a variable's value outside of your code ?
ABSOLUTELY!
>Obviously, while in kernel mode, you can't be interrupted by an IO that
>completes, right ? Or could an IO completing on another processor modify
>memory areas that your kernel code is playing with ?
Inner (any for that matter) mode code can be interrupted by many things --
interrupts, both software and hardware, and exceptions.
>But what about multiprocessor systems, can user mode code in one thread
>modify a variable that is being used by your kernel code running on
>another processor ?
This isn't anything new; SPINLOCKS were introduced in version V5 of VMS to
deal with synchronization of shared resources (memory) in a multiprocessor
configuration.
>And pardon my ignorance here, but when you issue a request to an IO
>device (aka: your code is the driver), I take it your code ends/returns
>once request is made, and then a totally new instance of your code
>begins when the driver sets a byte somewhere and the OS realises the IO
>device wants the driver to process something ?
As Simon had stated, you've obviously never written device drivers. Things
get queued and are driven by interrupts in driver code. Code in the driver
may need to wait in which case, the driver "forks". Once that thing that
the driver has been waiting for has occurred, the driver code is revisited
by the OS dispatching to where the driver forked. Context is saved in the
fork block to allow the driver to pick up where it left off. Think of it
as multi-threading if that helps you.
>aka: you don't wait for some value to change, you just return, knowing
>the OS will call you again when the value changes ?
RTFM on FORKing, and read Simon's and John Reagan's replies as well.
FWIW, there are other many other mechanisms which can be employed in VMS
to synchronize access to share resources by processes/threads -- MUTEXes,
for example. One needs to be very aware when multiprocessors and multi-
processes are sharing resources and one needs to coordinate how those
resources are shared.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
More information about the Info-vax
mailing list