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

[chris]

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 ?.

>
> 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 ?.

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

Chris