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

[chris]

On 09/24/21 19:36, Simon Clubley wrote:
> On 2021-09-24, chris<chris-nospam at tridac.net>  wrote:
>> On 09/24/21 13:16, Simon Clubley wrote:
>>> On 2021-09-23, chris<chris-nospam at tridac.net>   wrote:
>>>>
>>>> If you look at that use of volatile, it's dealing with sig_atomic,
>>>> which I would guess to be an interface to a test and set instruction,
>>>> which is  designed to be indivisible and non interuptable. That is,
>>>> the whole instruction always executes to completion.
>>>> More like driver level code, not application, where such
>>>> functionality would normally be encapsulated into a system call.
>>>>
>>>
>>> Volatile is also set (quite correctly) on the buffer itself.
>>>
>>
>> Why ?. While the compiler will typically pad out structures to align
>> each element to the machine wordsize, the use of volatile to define
>> that buffer looks redundant, since no optimisation would apply to
>> that structure definition anyway.
>>
>
> Chris, what makes you think you know better than the people who
> wrote that header ?

While I don't stubbornly claim to be always right, have spent over
three decades programming real time embedded on a variety of RTOS
platforms.

They put a volatile tag onto a void pointer, which can be
cast to pointer to any type, but still doesn't need the volatile
tag.

>
> It's not the structure, but the data written into the buffer by
> Linux behind the scenes that the volatile attribute is designed
> to address.
>

> The whole point of the AIO interface is that the data is written to
> the buffer in your process by Linux while your program is busy doing
> something else. In this case, it's behaving in exactly the same way
> that sys$qio() is behaving.

Shared memory regions are quite common in everyday code, asynchronously
updated or not, as the DMA example I outlined earlier. Perhaps you are 
not explaining what you mean very well ?.

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

Chris