volatile (in comp.lang.c)

[Eugene D. Brooks III]

In article <1036 at ima.ISC.COM> johnl at ima.UUCP (John R. Levine) writes:
>Not so fast, there. In large multi-CPU systems, there is often a write-behind
>cache and writes by one processor are not always visible to other processors
>until you do some sort of cache-flush operation. (For example, on 370
>architecture machines the cache is only flushed on process switch, start I/O,
>and a very slow flush no-op.)
Bus based multiprocessors which do not have automatic cache coherency
taken care of in the hardware are SICK as far as tightly coupled shared
memory multiprocessing is concerned.  If there is no automatic maintenance
of cache coherence one has to have to kinds of loads and two kinds of stores
to handle options of treatment of cached data.  Multiprocessors without
these needed features don't get used for tightly coupled multiprocessing,
they are used in throughput mode.  I stand by the need for volatile, I need
volatile for several programs I run on shared memory multiprocessors if an
"optimizing" compiler is to be used.  This is not "educated guesswork" or
"gut feelings" on my part.  I have been programming shared memory
multiprocessors for a half decade now and have been hosed over
by optimizing compilers many times.  Volatile is not a dead horse,
expect several manufactures who deliver shared memory multiprocessors to
have volatile with teeth in the future.  It is fundamentally important!