[Info-vax] yet another sys$qiow question

[John Reagan]

On Friday, August 21, 2015 at 7:01:06 PM UTC-4, Stephen Hoffman wrote:

> 
> It'll be interesting to see what HP and VSI might deign to document and 
> to recommend here, assuming this potentially-undefined behavior is 
> determined to be real.
> 

My recommendation is that if you have a variable that may be asychronously modified, then you should tell the compiler that fact with the volatile keyword.  If you can construct some sequence of events like using $SYNCH, etc. that would get the compiler to always refetch the IOSB, then adding volatile really isn't taking away any performance (unless you have code that then reads lengths, etc. from the other portion of the IOSB over-and-over again such that volatile would prevent caching).  Again, neither the compiler or the C standard any special knowledge of OpenVMS, $QIO, or ASTs.  Passing an IOSB to $QIO doesn't have any magical powers.

As mentioned earlier in the thread, the lifetime is also important.  Lets say you pass an IOSB to $QIO but don't ever check it.  From the compiler's point of view, the last use of the IOSB is the call to $QIO.  After that point, the compiler may decide to allocate another variable in those same stack locations (perhaps you had a variable that you didn't use until after the call to $QIO).  So when the system asychronously updates those stack locations thinking it is still the IOSB, it is actually trashing a different variable.  

The VMS compilers (and all the other compilers I've ever encountered), extend the lifetimes of variables declared volatile past their last use to minimize the risk.  However, you still have the problem of declaraing a stacklocal volatile IOSB, passing that to $QIO, and then immediately returning to your caller.  The IOSB update may update stuff above the stack pointer (no harm there) but if you then called another routine, the old IOSB may overlay who knows what.  That is just bad programming and lack of understanding of the $QIO routine.

Similarly, who calls $GETJPI instead of $GETJPIW?