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

[Simon Clubley]

On 2021-09-26, chris <chris-nospam at tridac.net> wrote:
> On 09/25/21 19:29, Simon Clubley wrote:
>> On 2021-09-25, chris<chris-nospam at tridac.net>  wrote:
>>> On 09/25/21 04:42, Simon Clubley wrote:
>>>> On 2021-09-24, chris<chris-nospam at tridac.net>   wrote:
>>>>> On 09/24/21 19:36, Simon Clubley wrote:
>>>>>> You therefore have to force a re-read of the buffer when you later go
>>>>>> looking at it so the compiler doesn't think it can reuse an existing
>>>>>> (and now stale) value.
>>>>>
>>>>> All i'm saying is, read the C standard docs on the use of the volatile
>>>>> keyword for more info, or do you think you know better ?...
>>>>>
>>>>
>>>> How do you otherwise _guarantee_ that the Linux application program
>>>> is seeing the latest data that the Linux kernel might have written
>>>> into the buffer behind the scenes since the program last looked at
>>>> the buffer ?
>>>>
>>>
>>> Most kernels have system calls to deal with that sort of thing, to
>>> create and manage locks on shared resources and to ensure mutual
>>> exclusion. The key thing is that that is a high level thing, whereas
>>> things like volatile are a compile time mechanism. If you like,
>>> the low level support foundation for high level lock mechanisms.
>>>
>>> Others may have a better explanation of all this...
>>>
>>
>> No explanation needed as I do understand those things.
>>
>> However, we were talking instead about why the AIO implementation
>> on Linux uses the volatile attribute on its transfer buffer.
>
> Yes, an i'm suggesting that it's redundant. Structures or their
> contents are not modified in any way by the compiler, other than
> possible padding out element spacing to the natural machine
> wordsize.  So again, why is that buffer pointer declared with
> the volatile keyword ?.
>

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.

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 :-)).

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.

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.
>>
>
> It's still not clear to me, so in the spirit of teamwork, why
> don't you explain that use of volatile, in depth, so we can
> all understand it ?.
>

I've explained above. It's not about the structure the pointer is a
part of. It's about the buffer behind the pointer.

> No later Linux here, but FreeBSD man aio produces:
>
> > The aio facility provides system calls for asynchronous I/O.
> > Asynchronous I/O operations are not completed synchronously
> > by the calling thread.  Instead, the calling thread invokes
> > one system call to request an asynchronous I/O operation.
> > The status of a completed request is retrieved later via a
> > separate system call.
>
> Key point there is: not completed synchronously by the calling
>                      thread...
>

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

That's two different operating systems so whoever designed this
interface was clearly worried about the possibility that compiler
optimisation could get in the way of this working correctly in
some cases.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.