[Info-vax] Volatile, was: Re: yet another sys$qiow question

[George Cornelius]

In article <55d73789$0$19629$c3e8da3$b1356c67 at news.astraweb.com>, JF Mezei <jfmezei.spamnot at vaxination.ca> writes:
> On 15-08-21 09:41, Johnny Billquist wrote:
>> 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.

> Pardon my ignorance here, but what purpose is served by checking the
> IOSB before the IO completes ?

I gave an example (TIMED_WAIT) in response to something Bob G. wrote.
I had a timer running at the same time as a read from mailbox and issued
a $WFLOR to wait on the logical OR of the two event flags.

When this completed, the quickest way to determine which one had completed
(and the best one, it turns out, because I was going to cancel the mailbox
operation if it had not completed) was to check the status word of the
IOSB.  Were it nonzero, the I/O would be, in a certain sense, complete.

But, on an Alpha, there is a crucial synchronization step still necessary,
or so I understand: the I/O completed, perhaps on another processor
without interrupting my own code thread, but on my current processor the
final write(s) to the input buffer, due to write reordering, are not yet
visible. A fix for that is to perform an extra system call at that point,
and that is what my code did, but it should also be possible on an Alpha
to just issue an MB instruction, which is designed to assure all pending
memory writes have completed from the current processor's point of view.

This may be something that is unique to Alphas.  [I'll start another
thread related to this when I get a chance].

> Is this some performance thing to check IOSB for non-zero value instead
> of checking if event-flag has been set ?

In my case I just needed to check which of the two system services had
completed.  And yes, I suppose I could have issued a $READEF, which is
slightly more expensive.  But in the VAX days checking the IOSB was
a perfectly legitimate way to do it, and the way it was written the
code turned out to still be correct (in my opinion, at least) on
transfer to the Alpha.

> I've always done either QIOW, or QIO with AST or QIO with event flag. I
> personally really like the AST model.

AST's are, I think, the magic bullet for this.  They really are
a simulated interrupt service routine that executes in your own
process context, and, in particular, should guarantee the
preservation of write ordering.

There may be a need for a volatile declaration of data that will
be modified by AST code, but the weakly volatile compiler
flagging that John mentioned may help out here, and as long as
you use _some_ synchronization system service to learn whether
the AST has fired you may be able to rely on that for anything
that is defined globally.  And remember the issues concerning
non-atomicity of operations such as ++x as seen at AST level,
solvable by such things as lib$adawi, lib$bbssi, and the
interlocked queue insertion and removal functions.

George