[Info-vax] yet another sys$qiow question

[George Cornelius]

In article <a1cd9359-51d6-46bc-91cb-fb1e36f394a8 at googlegroups.com>, Bob Gezelter <gezelter at rlgsc.com> writes:
> On Monday, July 20, 2015 at 2:14:33 AM UTC-4, George Cornelius wrote:
>> 
>>  o Know about the fact that realtime activities -
>>    examining the buffer while the i/o is underway,
>>    for example - run afoul of high level language
>>    constructs and optimization in general unless
>>    you take special precautions, including the
>>    use of the 'volatile' keyword in C.
>> 
> 
> George, 
> 
> Actually, looking at the buffer while the IO pending (IOSB Status
> PENDING) is simply undefined.

Well, thanks for trying to set me straight on that.

I did understand you could not do anything with what was in the buffer
without checking for completion first.  What I had completely forgotten
about the Alpha (and I have never really coded for Itanium other than
to verify that I could port a program or two) when we were discussing
this was that it is still unsafe to check the contents of the buffer
after you have verified the IOSB status value is nonzero.  There still
needs to by a memory barrier, from what I understand, because the
interrupt code could have been executing on a different processor and
in such a case local code is not guaranteed to see memory changes in
the order in which they occurred.

The easiest way to avoid that exposure is to actually test for
completion - issue the $SYNCH_S even if you know it will instantly
return, for example - before trying to access the buffer.  But issuing
a memory barrier instruction should work as well.

The TIMED_WAIT subroutine that I posted elsewhere is just about the
only example I have run across of my checking the IOSB before issuing
a wait for completion.  And, as I commented when I posted it, I
believe I can completely justify its use in both places where it
occurs in that small snippet of code.  The code and all the comments
are unchanged from the original VAX version, by the way.  The
Alpha changes were to add .align directives.

The whole volatile thing appears to have been a distraction.  As far as
I can tell, the C compiler never issues memory barrier instructions when
referencing volatile data, and, as John has pointed out, volatile is
not really needed as a hint to the compiler that the data might change
asynchronously as long as it already knows that the address of the
entity has been taken and passed to external code, because it
apparently has an internal implementation of a 'weakly volatile'
designation.  But if you do not synchronize, and it does change
between two successive calls to external code, the compiler is
free to remember, say, the value it read the first time in a
sequence of uninterrupted local code and not fetch it separately
each time thereafter.

And in all the C code I have written since 1990, about the time we
first got a VMS C compiler, I see two places where I declared a buffer
volatile.  One was production code but was only a single character
buffer.  The other was an earlier version of something I use pretty
much every day to autodetect terminal window size and pass that on
to the terminal driver.  But even then, it was single character
reads because a non-DEC terminal type that was being used way back
then and that was queried for as well was sending back escape
sequences that the terminal driver did not like.  Two exact
duplicates of that second program's declarations appear elsewhere,
but they both turn out to be one-off test programs.

Aside to Hoff: Thanks for the helpful comments, but I never spin
on I/O in a multiprogramming environment.

To me polling an IOSB means that, after I have gained control, I might
check for multiple completion events at one time and try to avoid being
awakened a second time if at all possible.  Again, the only example I
have of doing anything like that in VMS is in the TIMED_WAIT routine
I already posted.

George

> 
> Until the IOSB is set to the completion value, the contents of the
> buffer for ALL IO operations (not simply the terminal driver), are
> undefined. Thus, any code that looks at buffer contents prior to
> completion is simply incorrect.
> 
> - Bob Gezelter, http://www.rlgsc.com