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

Simon Clubley clubley at remove_me.eisner.decus.org-Earth.UFP
Sat Sep 25 14:29:24 EDT 2021


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.

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.

Simon.

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



More information about the Info-vax mailing list