Re: About volatile qualifier

From:

"Doug Harrison [MVP]" <dsh@mvps.org>

Newsgroups:

microsoft.public.vc.language

Date:

Tue, 01 Jul 2008 10:20:09 -0500

Message-ID:

<k2ik6411e3jb9sv67s19mqijk7pjsd3okg@4ax.com>

On Tue, 1 Jul 2008 09:16:14 -0500, "Ben Voigt [C++ MVP]"
<rbv@nospam.nospam> wrote:

I understand all that. What I don't understand is the difference between
the situation of accessing the variable from both the main program and an
interrupt handler (which is how pre-emptive threading works, in essence) and
the hardware FIFO case which Alexander said is permissible. Won't
performing memory-mapped I/O still be subject to reordering in the CPU if a
memory barrier isn't applied? Is the CPU expected to avoid reordering
memory accesses which touch memory mapped to devices, and if so, how does it
identify them? I thought such mapping was done at the level of
PCI/northbridge and not in the CPU itself.

I don't know about the hardware level, but at the C++ level, you have to
look to the implementation for any guarantees. The closest the standard
comes to addressing anything along those lines is in 1.9/9:

<q>
When the processing of the abstract machine is interrupted by receipt of a
signal, the values of objects with
type other than volatile sig_atomic_t are unspecified, and the value of any
object not of
volatile sig_atomic_t that is modified by the handler becomes undefined.
</q>

Since the "abstract machine" is single-threaded, and neither of you is
talking about "signals", the standard is effectively silent on your
concerns. (As far as I'm concerned, it might as well be silent on
sig_atomic_t. <g>)

--
Doug Harrison
Visual C++ MVP