BUGFIX: TORTURE.C - Fixes to allow builds with Compaq C

[John E. Malmberg]

On Tue, 10 Jul 2001, Michael Sweet wrote:

> "John E. Malmberg" wrote:
> > ...
> The volatile keyword was added to allow the compiler to make
> optimizations that assume that temporary results of pointer
> dereferencing won't change when the pointer is passed to another
> function, or that two pointer variables might be pointing at the
> same general area of memory (e.g., an implementation of strcpy...)

I believe that your interpretation of that statement is not correct.
The presence of the volatile qualifier allows the compiler to make
assumptions on optimizations on variables that *DO NOT* have
the volatile qualifier.

The volatile qualifer does a spot disabling of optimization for a
specific memory location, allowing the compiler to more aggressively
optimize the rest of the code.

Compilers that do not support the volatile keyword may need to have
some of their optimization disabled when accessing a shared memory
location.


For a clearer reference:

http://www.openvms.compaq.com/commercial/c/6180p008.htm#index_x_241

  "The volatile qualifier forces the compiler to allocate memory for the
  volatile object, and to always access the object from memory.
  This qualifier is often used to declare that an object can be
  accessed in some way not under the compiler's control.
  Therefore, an object qualified by the volatile keyword can be modified
  and or accessed in ways by other processes or hardware, and is
  especially vulnerable to side effects."

This tends to contradict much of what you wrote.
 
> > This would be in any case where the same physical memory location can be
> > referenced by multiple threads or processes.  Failure to do so can result
> > in the compiler missing a change to the value.
 
> The volatile keyword isn't really meant for that; MP issues extend
> well beyond C, which is why you usually use OS mechanisms for
> semaphores, message queues, etc.  All volatile really buys you in
> this case is a mechanism for correctly (not) caching shared global
> variables.

volatile is required for that.  The compiler does not have any other
way to know that the memory area in question may have changed.

The semaphores and message queues are needed so that the program knows
that the value has changed, but with out the volatile keyword, the
compiler could present an incorrect prior snapshot of the memory location.
(Unless optimisations are turned off)

In the case of two pointer variables referencing the same general area
of memory, and one of the pointer variables is in an external module that
the compiler does not know about, it is the memory location that is
volatile, not the pointer.  The address in the pointer variable is not
going to change with out the compilers's knowlege, and should not in this
case marked volatile.
 
-John
wb8tyw at qsl.network
Personal Opinion Only