RE: Race in MSCP (ra/rx) driver

[Mark Pizzolato - Info Comm <Mark%infocomm.com@localhost>]

On Wednesday, August 26, 2020 at 11:49 AM, Mouse wrote:
> >> [...race in rx_putonline...]
> 
> >> Presumably most real hardware isn't that fast, but something like an
> >> MSCP interface backed by RAM or, in my case, a simulation, can trip
> >> this race.  (simh has comments saying, to rephrase from memory, that
> >> VMS works with an infinitely fast MSCP disk, but the BSDs don't -
> >> this is likely part of what's behind the latter.)
> > Simh may have a comment like that, but the MSCP device simulator does
> > not implement infinitely fast I/O completion.
> 
> I know - the code was clear on that.  Presumably it is an attempt to work with
> code that depends on aspects of devices (like timing) that are not part of the
> interface contract.
> 
> The remark about simh was in parentheses because it was, well,
> parenthetical: it was a side note, related to my main point and possibly of
> interest, but not particularly important.

I understand, but a quick read of your message might have suggested to 
some that simh implemented infinitely fast I/O.

> I was operating on the assumption that NetBSD cared about races in their
> code even if running afoul of them requires unusual circumstances, such as
> hardware that is much faster than most.  (I don't know whether a real-
> hardware MSCP interface backed by something like semiconductor RAM
> instead of something more conventional like spinning rust exists, but I see no
> reason it couldn't, especially since AA-L619A-TK specifically mentions such a
> thing.)
> 
> In this case, I don't know how many instructions - or, for even greater
> precision, how many clock cycles - it takes before tsleep reaches the point
> where it won't break the code for the interrupt to arrive, but I'm sure it's
> greater than zero and thus the race could be tripped by fast but not infinitely
> fast hardware.  Using infinitely fast pseudo-hardware is just a convenient
> way to find such races.  (In the case of my simulator, not infinitely fast, but
> close enough there's little practical difference - there is, I think, one
> instruction of delay, not because I want delay but because that's how the
> mechanisms I built to get everything to happen in the right order worked
> out.)

Covering that case is absolutely a good idea, but in practice, real hardware 
had microprocessors implementing the nuts and bolts of both the CPU 
interactions and the rest of the job of the MSCP device.  These microprocessors 
essentially always were slower than the processor they were connected to, 
with a good number of microprocessor instructions just to fetch and interpret 
the info in the command that needs to be processed, so even if data access 
had no mechanical delays the interpretive overhead could never be very 
close to 0.

An interesting thing to observe is that a VAX780 simulator booting from an 
RM03 simulated device actually boots noticeably faster than the same 
simulator booting from an MSCP device.  The I/O completion delays that 
were needed for the RP device were significantly shorter and involved 
fewer interactions than the MSCP (RQ) case.

- Mark