Re: Doug Harrison, please!

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Carl Daniel [VC++ MVP] (cpdaniel_remove_this_and_nospam_at_mvps.org.nospam)
Date: 02/07/04 

Date: Sat, 7 Feb 2004 11:01:36 -0800

fh1996 wrote:
> Thanks to everyone who answered my questions about SEH, specifically
> "volatile" one!
> (Please see thread: SEH and standard C++ exceptions)
>
> I have some more questions, which is regarding Doug Harrison's post:
>
> // Assuming everyone observes the locking protocol, this approach
> // would work on all hardware, even weird architectures like Sparc
> // and others which require memory barriers:
>
> bool x = true; // As above, just non-volatile
>
> for (;;)
> {
> lock(mx);
> bool y = x;
> unlock(mx);
> if (!y)
> break;
> whatever;
> }
>
> This is new and interesting to me. Is this solution better than using
> "volatile bool x = true;"?

Better in that it's actually guaranteed to work on all multi-processing
systems, yes. As Doug mentioned, on some architectures (Sparc64 being one
of them) it will actually cause a hardware fault if you access a variable
from two different CPUs without an intervening memory barrier. The
OS-supplied synchronization mechanisms always include the necessary barrier
instructions to guarantee that this sort of idiom works. If you ever plan
to move your code to IA-64 (Itanium), you'll need to use this technique
because it too requires memory barriers between multi-CPU accesses to a
single memory location.

The volatile idiom works on IA-32 machines because these systems implement
strong cache coherency between processors in an SMP machine. This strong
cache coherency allows for fairly sloppy programming (from a
multi-processing standpoint), but it comes at a cost: the bus bandwidth
consumed by maintaining strong cache coherency between multiple processors
limits the scalability of IA-32 based machines (that's why you rarely see
more than 8 CPUs in an IA-32 machine). Highly scalable architectures, such
as Sparc and Itanium don't have a strong cache coherency characteristic as a
result programming for them requires more discipline but the resulting
systems scale better.

>
> "2. You need volatile to avoid undefined behavior in certain signal
> handler and setjmp/longjmp scenarios."
>
> Would you mind to give us some examples about this?

These are defined by the POSIX and C standards.

>
> "3. You can use volatile, say, to declare a pointer to a volatile
> int, which represents a memory location updated at the interrupt
> level, something you can't synchronize with, and which is outside the
> compiler's knowledge of the program."
>
> This is totally beyond my apprehension. Would you please elaborate
> more on this point?

I assume you mean comprehension, not apprehension...

Originally, volatile was intended to be used to help with low-level device
drivers which interface with memory-mapped hardware. Such hardware appears
in the memory address space, but isn't memory per-se. Instead, it's some
arbitrary functionality that can be read and/or written - but unlike memory,
with hardware there's generally no guarantee that if you write something to
a location that you'll read that same something back when you later read
from that location. Volatile tells the compiler that the variable may
change values in ways that the compiler can't know about, such as underlying
hardware.

In Doug's example, rather than being memory-mapped hardware, a volatile
variable might be used to communicate between code that runs as a result of
a hardware interrupt (which the compiler also doesn't know about) and some
other code. Again, this kind of usage will typically only appear if you're
writing "close to the metal", such as in embedded work or device driver
development.

HTH

-cd

Relevant Pages

  • Re: What is the meaning of this warning, and how do I get rid of it?
    ... applications such as device drivers and memory-mapped I/O. ... %% A static volatile object is an appropriate model for a memory ... %% take into account relevant hardware details on the target systems ... Some machines reserve memory addresses such that reads from or writes ...
    (comp.lang.c)
  • Re: Embedded software interview question collection
    ... grips what volatile really does and because of this the new piece ... memory corruption. ... but what has the use of volatile got to do with cache? ... Say the variable is really a hardware status bit, ...
    (comp.arch.embedded)
  • Re: Embedded software interview question collection
    ... grips what volatile really does and because of this the new piece ... memory corruption. ... Say the variable is really a hardware status bit, ... caching to memory mapped I/O regions. ...
    (comp.arch.embedded)
  • Re: local_irq_save, memory clobbering and volatile
    ... > comments about volatile: ... >> makes the compiler generate worse code without ever fixing any real ... the hardware is hardware. ... > When memory gets clobbered the compiler can't optimize other memory ...
    (Linux-Kernel)
  • Re: High memory
    ... memory and then copy it up above 1MB...but if you want to put ... outside the CPU, memory is seen in a completely different light...this ... 1MB with "real mode memory" labelled on it or anything...the actual memory ... the system bus to actual hardware devices...hence, ...
    (alt.lang.asm)