On Thu, 2015-04-16 at 20:15 +0200, Peter Zijlstra wrote: > On Thu, Apr 16, 2015 at 08:02:27PM +0200, Ingo Molnar wrote: > > > ACCESS_ONCE() is not a compiler barrier > > > > It's not a general compiler barrier (and I didn't claim so) but it is > > still a compiler barrier: it's documented as a weak, variable specific > > barrier in Documentation/memor-barriers.txt: > > Ok, fair enough. I just don't generally think of them as 'barriers'. > > > > The 'read' side uses ACCESS_ONCE() for two purposes: > > > - to load the value once, we don't want the seq number to change under > > > us for obvious reasons > > > - to avoid load tearing and observe weird seq numbers > > > > > > The update side uses ACCESS_ONCE() to avoid write tearing, and > > > strictly speaking it should also worry about read-tearing since its > > > not hard serialized, although its very unlikely to actually have > > > concurrency (IIRC). > > > This is what I meant by that there's no harm from this race. > > Ok, but I would still like to preserve the READ one on the usage site > and the WRITE one on the update side, if only as documentation that > there's something 'special' happening.
In that case, in our patch 2, I suppose we also want to use READ_ONCE() when accessing the running field, which also helps document that we're reading and writing to a non-atomic value that gets accessed without a lock. > And while the effects here might end up being statistical noise, I have > conceptual problems with re-reading seq counts, that's not proper. > > And its not like they really cost anything. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
