[Info-vax] yet another sys$qiow question

[Johnny Billquist]

On 2015-08-21 14:57, 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.

Uh? It's a completely valid and not poor practice to check the iosb 
before the operation completes. And the IOSB is defined as being set to 
zero by the initiation of the I/O.

>> 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:

There is no iosb to the QIO written either. What do you think 
<arguments> mean?
And I pointed out it was pseudocode.

And what do you thing <wait for I/O completion> meant then?

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

What is wrong with checking the IOSB before the I/O completes? There is 
absolutely nothing wrong with that. And if it is non-zero, it means the 
I/O already have completed, so there is no point in waiting, since it 
will return immediately.

In fact, SYS$SYNCH is doing exactly the same thing. It waits for the 
event flags, and then it checks if the IOSB is non-zero. If it is still 
zero, then it means something else set the event flag, and the I/O is in 
fact still not finished.

Or that is my understanding of SYS$SYNCH. Correct me if I'm wrong.

Oh, and SYS$SYNCH might actually declare the IOSB parameter as a 
read-only, which means the compiler will know SYS$SYNCH itself will not 
modify it, so the compiler can cache through that call.
Because SYS$SYNCH will in fact not modify the IOSB. But on the other 
hand, the programmer writing the prototype for the function might be 
more clever and know that as a side effect of waiting for the I/O to 
complete, the IOSB will change its value, so while SYS$SYNCH itself is 
not modifying it, when SYS$SYNCH returns, the IOSB value will still have 
changed its content as a side effect of the I/O completing.
But then again, a clever compiler itself will notice, when compiling the 
SYS$SYNCH code that the IOSB is declared as writeable, but the code 
never writes to it, so that could be a warning of its own in this case.

> You've convinced me that you do understand how volatile works. Whether
> you understand how to use SYS$QIO on VMS is more doubtful.

I'll not try to argue with you about what you think.

	Johnny