[Info-vax] yet another sys$qiow question

[Johnny Billquist]

On 2015-08-19 14:51, Stephen Hoffman wrote:
> On 2015-08-19 12:18:30 +0000, Bob Gezelter said:
>
>> Then I am (reluctantly) forced to agree with Hoff. There is a large
>> collection of code with latent problems in the examples.
>
> John: I'd (and respectfully) suggest reviewing the old internal notes
> conferences — assuming those are available to VSI, as I recall various
> internal discussions of this particular topic over the years; but I
> don't recall off-hand whether the system service calls effectively
> always contribute barriers that obviate the need for the volatile
> keyword here.

A barrier will not make any difference from this point of view. Barriers 
ensure that the data hits memory. Volatile ensures that the code 
actually reads from memory. It don't help if you make sure the data is 
in memory, if the code do not read from memory.

Exmaple:
   x = iosb;
   y = iosb;

The C compiler can easily compact this into just one read of the iosb 
variable, even if your source code have two reads. And if the system 
actaully changed the value between these two reads, then you could argue 
that y got the wrong value.

Even more fun:

   while (iosb == 0) ;

This code will spin until iosb is non-zero. However, the C compiler can 
easily detect that iosb == 0 is an invariant. The iosb variable is not 
changed in the loop, and therefor do not need to be read for every 
iteration. The compiler can optimize this to just read the iosb once 
before the start of the loop, and then just conditionally loop for ever. 
And if iosb is not modified outside of the flow of this program, that 
optimization would be entirely correct.

So, you need to tell the C compiler that iosb can indeed be modified 
outside of the flow of the program, so that the compilar cannot make 
optimizations with regards to the read of the iosb variable. And that is 
what volatile do.

> If volatile is required here — and my quite-possibly-wrong recollection
> was that the compiler and the system service calls for $synch or the EF
> checks were sufficient — then please take the time in the documentation
> and the source code examples to create what will now be the proper
> coding practice, and — while you're at it — also please figure out if
> there are any other changes that you might want to or need to make in
> this same area (possibly up through changes that might be appropriate
> for x86-64 and/or C11 support?), prior to having us all reworking a
> gazillion C source modules.   If I have to change a zillion source
> modules, I'd prefer to do it once.
>
> Fortran also has a VOLATILE, whether that will be necessary in Fortran
> code?  Here's an example that explicitly discusses the use of Fortran
> VOLATILE, and does not show VOLATILE used with the IOSB:
> http://h71000.www7.hp.com/doc/82final/6443/6443pro_049.html

I'll leave this to John. :-)

	Johnny