[Info-vax] yet another sys$qiow question

[John Reagan]

On Tuesday, August 18, 2015 at 7:45:35 PM UTC-4, George Cornelius wrote:

> 
> The whole volatile thing appears to have been a distraction.  As far as
> I can tell, the C compiler never issues memory barrier instructions when
> referencing volatile data, and, as John has pointed out, volatile is
> not really needed as a hint to the compiler that the data might change
> asynchronously as long as it already knows that the address of the
> entity has been taken and passed to external code, because it
> apparently has an internal implementation of a 'weakly volatile'
> designation.  But if you do not synchronize, and it does change
> between two successive calls to external code, the compiler is
> free to remember, say, the value it read the first time in a
> sequence of uninterrupted local code and not fetch it separately
> each time thereafter.

You don't need memory barriers.  You do need volatile.  The IOSB is written behind your back.  volatile says we have to re-fetch.  

I think you misunderstood my prior posts.  Places that only need a 'weak volatile' are places where you took the address of something (for example, put the address of a variable into an item list descriptor) and then call some system service that would write that variable for you.  But C doesn't have a weak volatile.  You can get away without using volatile, but in general, I'd recommend it at least for documentation purposes.

You only need memory barriers when you need to define an order of reads & writes to DIFFERENT memory locations.  For example, if you have a buffer and a 'buffer-ready' flag, you want a memory barrier between the writes to the buffer and the write to the ready flag to make sure the buffer is indeed written before you set the flag.