Messages in this thread | | | From | Linus Torvalds <> | Date | Sat, 17 Aug 2019 01:44:04 -0700 | Subject | Re: [PATCH 1/1] Fix: trace sched switch start/stop racy updates |
| |
On Sat, Aug 17, 2019 at 1:28 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > unsigned int bits = some_global_value; > ...test different bits in in 'bits' ... > > can easily cause multiple reads (particularly on a CPU that has a > "test bits in memory" instruction and a lack of registers. > > So then doing it as > > unsigned int bits = READ_ONCE(some_global_value); > .. test different bits in 'bits'...
Side note: this is likely the best example of actual WRITE_ONCE() use too: if you have that global value with multiple bits that actually have some interdependencies, then doing
some_global_value = some_complex_expression();
might be reasonably compiled to do several rmw instructions to update 'some_global_value'
So then
WRITE_ONCE(some_global_value, some_complex_expression());
really can be a good thing - it clearly just writes things once, and it also documents the whole "write one or the other" value, not some mid-way one, when you then look at the READ_ONCE() thing.
But I'm seeing a lot of WRITE_ONCE(x, constantvalue) kind of things and don't seem to find a lot of reason to think that they are any inherently better than "x = constantvalue".
(In contrast, using "smp_store_release(flag, true)" has inherent value, because it actually implies a memory barrier wrt previous writes, in ways that WRITE_ONCE() or a direct assignment does not.)
Ok, enough blathering. I think I've made my point.
Linus
| |