[Info-vax] yet another sys$qiow question

[John Reagan]

On Friday, August 21, 2015 at 8:57:45 AM UTC-4, Craig A. Berry wrote:
> On 8/21/15 7:19 AM, Johnny Billquist wrote:
> > On 2015-08-21 14:07, David Froble wrote:
> 
> >> Thanks for validating Craig's statement.  You don't test the IOSB for
> >> completion.  If you're doing async I/O, then you wait for the AST or
> >> whatever to tell you it's complete.
> >
> > Are you saying that it is a poorly written program if it do not use ASTs???
> 
> It's poorly written if it does not use a documented method to make sure
> the I/O completes *before* reading the value of the IOSB, a point I have
> made and you have ignored multiple times. ASTs are one of the documented
> methods.
> 
> > My example code will wait on the event flag. And it will fail if you
> > don't declare the iosb as volatile.
> 
> There is no event flag in your sample code, which consisted in its 
> entirety of:
> 
> SYS$QIO(<arguments>);
> if (iosb == 0) {
>    <do some stuff>
>    <wait for I/O completion>
>    printf("IOSB is now %x\n", iosb);
> }
> 
> Unless "wait for I/O completion" means wait for an event flag? If it
> means SYS$SYNCH, then you'd be fine because that takes the address of
> the IOSB and the compiler would know someone else might modify it. If it
> is an event flag firing then yes, the printf might say iosb is zero even
> though it changed in the meantime, but only because you checked its
> value before ensuring that the I/O completed. Which is wrong, so don't
> do that.

Since the IOSB was passed to $QIO, the compiler now worries that $QIO saved the address (it did).  If you call $WAITFR, the compiler would be worried that $WAITFR has access to the saved IOSB address.  I would expect the IOSB to be refetched for that printf.  (The compiler DOES know about RTL routines like printf that don't have side-effects.)