Re: __{read,write}_once

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 11 Nov 2019 21:32:06 +0100
    From:        Joerg Sonnenberger <joerg%bec.de@localhost>
    Message-ID:  <20191111203206.GA4678%bec.de@localhost>

  | The update needs to be uninterruptable on the local CPU in the sense that
  | context switches and interrupts don't tear the R and W part of the RMW cycle
  | apart.

If I understood the original message, even that was not required.

All that was really demanded was that each of the R and W oarts
not be split into pieces where an intervening interrupt might alter
the "other" part, allowing a read to receive, or a write to produce,
a value that neither the basline code, nor the interrupt routine
even intended.

But in
	x += 2;
if an interrupt intervenes and does
	x += 1;
it is acceptably for the evential reault to be old_x + 1 (which is very
unlikely), old_x + 2, or old_x + 3, but only those.

That's how I understood the "racy is OK" part of it.  Ie: we don't care
about race conditions like this.

What we don't want is if x started out at 0000FFFF and is read in 2
halves, for the base code to read the 0000 half, then the interrupt to
change the value to 00010000 and then the base code to read 0000 for the
bottom half, leading to a reasult of 1 in x, rather than 00010000 or 00010001
which is not acceptable (or anything else like that, and similarly for
writes).

Or in other words, it is acceptable for some uses for the occasuonal
change to be lost (particuarly for some event counters) if it is not
likely to happen frequently, but not for entirely bogus values to appear.

kre