[Info-vax] QIO Writes to a mailbox

[Johnny Billquist]

On 2011-11-10 00.21, Jan-Erik Soderholm wrote:
> Johnny Billquist wrote 2011-11-10 00:05:
>> On 2011-11-09 23.40, Jan-Erik Soderholm wrote:
>>> The same logic applies. Don't wait for the AST right after the QIO call.
>>> Wait for the AST right before the next QIO call. That is, do any other
>>> processing (that is not depending in the IO completion) without waiting.
>>
>> Um? You don't wait for an AST. There is no "wait for AST" system call.
>
> No, of course not, since it's an (kind of software) interrupt. But
> nevertheless. The AST must have fired before you make the next QIO.
> I'm not sure what you do, HIB maybe ? Let's say you'll HIB.
>
> My whole point is that ("HIB" = "wait for the AST") :
>
> $QIO => prepare next IO => HIB => $QUI => prepare next IO => HIB....
>
> is more efficient then :
>
> $QIO => HIB => prepare next IO => $QUI => HIB => prepare next IO....
>
> In the first case "prepare next IO" will be done in parallell
> with the IO processing. In the second the application will never
> do anything during IO processing (apart from hibernating).
>
> Maybe the IO complets during "prepare next IO" and in that case
> the HIB might not be needed at all. That (if the AST has fired)
> can be checked before hibernating.
>
> Now, *if* hibernating is what one does. But that is not important
> for *this* discussion. :-)

Right.
But even more efficient is:
$QIO => $QIO => hibernate/work/whatever.
And in the AST:
Check completion => prepare I/O => $QIO => exit ast.

>>> This is common logic for any programmning. If you do anything that takes
>>> some times and that you have to wait for, wait (if neeed) *before*
>>> you do
>>> the call, not after. That way you do not wait if it's not needed.
>>
>> Well, yeah, you could put it that way. It does take some extra setup at
>> startup though, so you don't fail already at the start. Much nicer with
>> ASTs really.
>
> The only way AST changes things is "who is telling who" about the IO
> completion. It doesn't change the fact that you can not make a second
> $QIO before the first has completed. AST's just change the way
> you know that it has completed.

Sure you can do the second QIO before the first one completes. What made 
you think you couldn't? And if you are interested in efficient I/O, 
that's the way to go. Absolutely minimal overhead between the completion 
of one I/O and the start of next, since you don't even have the delay 
introduced by the delivery of the AST/event flags, and the processing of 
the QIO system call between the I/O requests.

But it all still boils down to a few important details:
1) Check the result of the QIO to know if an I/O even got queued
2) Don't touch I/O buffers while the I/O is outstanding.
3) Check the IOSB for the result of the I/O request.

Obviously, if 1 fails, then 2 and 3 are not valid.

	Johnny