[Info-vax] QIO Writes to a mailbox

[Bob Gezelter]

On Nov 4, 5:04 am, Steve Bainbridge <stephen_bainbri... at yahoo.co.uk>
wrote:
> Hi,
>
> I have a very simple question, but when looking at the Alpha internals
> manual and talking to colleagues the answer does not seem so obvious.
>
> We have some old code that issues a QIO WRITEVBLK to a mailbox - the
> return code from the QIO is normal. Another process reads the mailbox
> and never gets the message - this only happens very rarely.
> Unfortunately the writer does not check or report what value the IOSB
> returns and I need to try and understand why these messages are
> getting lost. I can't reproduce this on our test systems and I can't
> easily install updated diagnostic code onto these production systems.
>
> The question I have is when is the data pointed to by P1 (in the QIO
> call) actually copied ? It is always done within the QIO routine or is
> it just scheduled to be done in the QIO call ? Can I re-use the buffer
> pointed to by P1 immediately after the call to the QIO ?
>
> Regards,
> Steve

Steve,

As has been said several times: QIO (or QIOW) without checking the
IOSB status at completion is simply incorrect. The return from the
system service merely indicates that the operation was queued, not its
final disposition.

Bob Koehler hinted at an important distinction, which I will make
explicit: This is a conceptual issue, not a question to be determined
by experimentation. QIO (and QIOW) merely deliver information to the
driver's queue. The IOSB indicates the final disposition. Drivers are
free to do as they please between the time that the QIO is executed
and the time that the IO is completed. More importantly, going forward
(or backward), there are no guarantees that intermediate behavior will
be conserved. The contents of input buffers is UNDEFINED until IO
Complete, the contents of output buffers must be retained until IO
Complete.

Any differing behavior is erroneous and should be corrected.

Effective AST Programming requires care, my presentations on AST
programming from DECUS past can be found at http://www.rlgsc.com/presentations.html
(1995-2001).

- Bob Gezelter, http://www.rlgsc.com