On Wed, Nov 20, 2013 at 8:53 PM, Paul E. McKenney
<paulmck@xxxxxxxxxxxxxxxxxx> wrote:
>
> The other option is to weaken lock semantics so that unlock-lock no
> longer implies a full barrier, but I believe that we would regret taking
> that path. (It would be OK by me, I would just add a few smp_mb()
> calls on various slowpaths in RCU. But...)
Hmm. I *thought* we already did that, exactly because some
architecture already hit this issue, and we got rid of some of the
more subtle "this works because.."
No?
Anyway, isn't "unlock+lock" fundamentally guaranteed to be a memory
barrier? Anything before the unlock cannot possibly migrate down below
the unlock, and anything after the lock must not possibly migrate up
to before the lock? If either of those happens, then something has
migrated out of the critical region, which is against the whole point
of locking..
It's the "lock+unlock" where it's possible that something before the
lock might migrate *into* the critical region (ie after the lock), and
something after the unlock might similarly migrate to precede the
unlock, so you could end up having out-of-order accesses across a
lock/unlock sequence (that both happen "inside" the lock, but there is
no guaranteed ordering between the two accesses themselves).
Or am I confused? The one major reason for strong memory ordering is
that weak ordering is too f*cking easy to get wrong on a software
level, and even people who know about it will make mistakes.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>