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

[Bob Gezelter]

On Thursday, August 27, 2015 at 11:39:09 AM UTC-4, JF Mezei wrote:
> On 15-08-27 05:45, Johnny Billquist wrote:
> 
> > Polled I/O is not a sane way to go.
> 
> Yes it is, if you're on DOS on an 8086 that has no power management
> features and consumes as much power whether you are in an infinite loop
> checking the IOSB or infinite loop waiting for something else :-)
> 
> 
> > WIth ASTs or event flags, you 
> > normally do not "monitor" them. You just wait until they happen.
> 
> However, here is one legit possibility:
> 
> A timer expires, so you then check the IOSB for the IO to ensure it
> truly hasn't completed yet and if still null, you do the $CANCEL thing.
> 
> 
> (purists will say that you should check event flag for the IO instead of
> IOSB, but it appears that many accept checking for non-zero IOSB to do
> the job).
> 
> Note that this would be a one time check, so not likely to trigger the
> "volatile" check, but could have some race condition if IO completes
> between the timer AST being started and you checking the IOSB inside
> that AST.

JF,

Mixing timers and IO requires care. I have seen many problems when the timer times out, and data structures are recycled before the IO has actually completed. It is important to note (as has been previously commented upon in this thread) that issuing a $CANCEL on a channel DOES NOT guarantee that structures may be reused, only the IO completion event is a release.

Thus, the only safe thing to do in a timeout situation is to set a status flag in a data structure (often in a prefix or suffix to the IOSB/buffer) and cancel the IO. 

IO Completion will then occur. The IO completion routine can determine if the IO was cancelled or completed normally and act accordingly.

Obvious footnote that the above description does not apply to drivers (e.g., TTDRIVER) which have semantic concepts relating to timeout.

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