volatile isn't necessary, but it's there

[Guy Harris]

> The third hope for volatile, namely shared memory, is in some ways the
> most interesting because it nibbles at the edge of mechanisms
> that will become more important in the future.  Nevertheless,
> as several have pointed out, the Standard conspicuously avoids
> the extensions needed to make shared memory work
> (e.g. semaphores).  The dpANS even says, "what constitutes
> an access to an object that has volatile-qualified type is
> implementation-defined," and the sections that discuss
> what volatile actually does mean are correspondingly inexplicit.
> If you hope to find in the Standard that "extern volatile mutex; ++mutex"
> has an iron-clad meaning, you'll be disappointed.

It is worth noting, for example, that there is no guarantee that "++mutex" is
an atomic operation.  It is, in fact, worth noting that even if "extern
volatile char mutex;" was used, there would be no guarantee that "++mutex" is
atomic.  In all cases, for example, "++mutex" takes an instruction to load
"mutex" into a register, an instruction to increment it, and an instruction to
store it, on a SPARC.  The same would be true of any other architecture lacking
an instruction performing an "add 1 to memory" operation.

This is a real problem; there were some mildly entertaining bugs on Sun-4
caused by statements such as "++mutex;" in the kernel not being surrounded by
"spl" calls.