Date: Mon, 11 Nov 2019 21:32:06 +0100 From: Joerg Sonnenberger <jo...@bec.de> Message-ID: <20191111203206.ga4...@bec.de>
| 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