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

[Simon Clubley]

On 2021-09-24, chris <chris-nospam at tridac.net> wrote:

Chris, you are even more stubborn than Arne. :-) (Sorry Arne :-))

> On 09/24/21 13:09, Simon Clubley wrote:
>> On 2021-09-23, chris<chris-nospam at tridac.net>  wrote:
>>>
>>> Still doesn't explain why a volatiie keyword might be needed at
>>> application level, though I guess there might be a few edge cases...
>>>
>>
>> I'm surprised you are having a hard time seeing it Chris.
>>
>> Hardware stuffs something directly into process memory outside of
>> the flow of execution of a program, hence volatile may be required
>> for some programs to tell the compiler to generate code to re-read
>> it again.
>>
>
> Sorry, but that's incorrect. You are confusing compile time actions
> with runtime  situations. Present C compilers can have no
> knowledge of future dynamic runtime situations where, for example, a
> shared buffer may be updated asynchronously by separate processes
> and at different times. However, most operating systems have features
> to manage such situations to ensure things like mutual exclusion and
> deadlock  prevention. Os books are full of algorithms for that sort
> of thing, as it's so fundamental to OS design.
>

No I am not. All I have said all along is that volatile inserts code
into the generated code to _always_ re-read the variable before doing
anything with it.

Some programs may not need that but only if they have not touched the
variable since the program started running (so the initial read is what
would be done anyway).

I have _never_ said that compilers have any knowledge of dynamic runtime
situations. Volatile guarantees an unconditional read before working
with data and that is all it does and that's how unknown situations are
handled.

BTW, what does the hardware (or the operating system) dropping data you
requested into your process memory space while you busy doing something
else have to do with mutual exclusion or deadlocks ?

If you have not done such things, you might want to try writing programs
to use sys$qio() in full async mode or try the Linux AIO stuff and you
may then see what my potential concerns are with the upcoming compiler
changes.

>> VMS stuffs something directly into process memory outside of
>> the flow of execution of a program, hence volatile may now be
>> required for some programs to tell the compiler to generate code
>> to re-read it again.
>>
>> Simon.
>
> Sorry, but wrong again and it does nothing of the sort. All the
> volatile keyword does is to tell the compiler to disable
> optimisation across sequence points, ie: eg not unroll loops, not
> delete whole sections of apparently redundant code etc, but to
> generate code as per the source defines. No added code is or can
> be generated to take account of future run time situations.
>

Telling the compiler to generate code to re-read it again is _exactly_
what volatile does.

And telling the compiler to add code to force a re-read of a variable
_is_ the way you take account of unknown future run time situations.

Simon.

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