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

[chris]

On 09/22/21 19:11, Simon Clubley wrote:
> On 2021-09-22, Bob Gezelter<gezelter at rlgsc.com>  wrote:
>> Simon,
>>
>> Since the days of RSX-11M, I have been dealing with client bugs in this area.. The best phrasing I have seen in this area was in an IBM System/360 Principles of Operation manual. It may have only appeared in certain editions, as I cannot find the precise reference. However, it was along the lines of "the contents of a buffer are UNDEFINED [emphasis mine] from the initiation of the I/O operation until the operation has completed with the device end signal from the device."
>>
>> In OpenVMS speak, the above translates as: "The contents of the buffer are undefined from the issuance of the QIO system call until such time as the I/O is completed, signaled by the queueing of an AST; setting of an event flag; or the setting of the completion code in the IOSB."
>>
>
> That isn't the concern Bob.
>
> The concern is, given the highly asynchronous nature of VMS I/O and
> of some VMS system calls in general, and given the more aggressive
> LLVM optimiser, does the generated code always correctly re-read the
> current contents of buffers and variables without having to mark those
> buffers/variables as volatile ?
>
> Or are there enough sequence points in VMS application code where these
> buffers and variables are accessed that this may turn out not to be a
> problem in most cases ?
>
> In essence, the VMS system call and I/O system is behaving much more
> like the kinds of things you see in embedded bare-metal programming
> than in the normal synchronous model you see in the Unix world.
>
> There's a reason why volatile is used so liberally in embedded bare-metal
> programming. :-)
>
> Simon.
>


That sounds like bad code design to me and more an issue of critical
sections. For example, it's quite common to have an upper and lower io
half, with queues betwixt the two. Upper half being mainline code that
has access to and can update pointers, while low half at interrupt
level also has access to the queue and it's pointers. At trivial level,
interrupts are disabled during mainline access and if the interrupt
handler always runs to completion, that provides the critical section
locks.

What you seem to be suggesting is a race condition, where the state of
one section of code is unknown to the other, a  sequence of parallel
states that somehow get out of sync, due to poor code design, sequence
points, whatever.


I'm sure the designers of vms wpuld be well aware of such issues,
steeped in computer science as they were, and an  area which is
fundamental to most system design...

Chris