[Info-vax] LLVM, volatile and async VMS I/O and system calls

[chris]

On 09/27/21 19:49, Simon Clubley wrote:

>>
>
> Because the buffer behind the pointer gets directly written to by the
> operating system outside the normal flow of execution while the program
> is busy doing something else.

Yes,. it does, but the compiler has no knowledge of that at all, as it's
a run time thing, not compile time. Unless the compiler has a crystal
ball :-). Can have no idea of what underlying code might modify the
buffer.

>
> At that point, any cached contents of that buffer become invalid
> and need to be re-read. Volatile guarantees that will happen and _if_
> the code walks through a sequence point before reading the modified
> buffer that should cause it to happen as well (ignoring possible
> optimiser bugs :-)).

No, volatile does no such thing. It's merely a hint to the complier to
apply no optimisation to it.

>
> However, volatile, which has no downsides other than a few extra
> cycles, will _guarantee_ that will happen without you having to worry
> about if you have gone through a sequence point or if the optimiser
> has done something unexpected.
>
> This is no different from hardware writing directly into your memory
> space from outside the normal flow of execution of your code.

Quite common in interrupt handlers, but again, the compiler can't
predict the future as to when it will be modified, or by whom,
so how can it add code to mitigate what it can't understand ?.

>
> For the record, I always mark any buffers and data structures used in
> _truly_ asynchronous operations in applications as volatile these days
> to avoid any unexpected issues. I consider it an example of robust
> programming that avoids a whole range of potential problems.
>
> I'm also more worried about sys$qio() in async mode and the other VMS
> async system calls than in AIO as I used AIO as a second example of
> asynchronous I/O. The volatile attribute on the AIO buffer is correct,
> but given the variety of options in VMS, there's much more potential
> there for "funny stuff" :-) to happen in VMS.
>
>>>
>>> Perhaps if you play with the Linux AIO interface and especially with
>>> the sys$qio() system call in full async mode, you might understand
>>> why I am saying the things I am.
>>>
>>

That's how this started, right, VMS sys$qio having bugs internally ?.

>
> I've just checked some FreeBSD headers available online and it
> turns out that AIO on FreeBSD also marks the transfer buffer
> as volatile.
>

Well, there is a lot of cross fertilisation between the two OS. The
only reason I can think of for the pointer to be declared with
a volatile keyword is that if the buffer is declared volatile, then
the point also needs to be to avoid whinges about incompatible types.
Can see no reason for it otherwise...

Chris