Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Race in MSCP (ra/rx) driver



>> [...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 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.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index