On Mon, Jul 20, 2020 at 06:48:50PM +0200, peterz@xxxxxxxxxxxxx wrote: > On Mon, Jul 20, 2020 at 09:04:34AM -0700, Paul E. McKenney wrote: > > 2. If we were to say "unlock" instead of "release", consistency > > would demand that we also say "lock" instead of "acquire". > > But "lock" is subtlely different than "acquire", and there is > > a history of people requesting further divergence. > > This, acquire/release are RCpc, while (with the exception of Power) > LOCK/UNLOCK are RCsc. > > ( Or did we settle on RCtso for our release/acquire order? I have vague > memories of a long-ish thread, but seem to have forgotten the outcome, > if any. ) > > Lots of subtlety and head-aches right about there. Anyway, it would be > awesome if we can get Power into the RCsc locking camp :-) I will let you take that one up with the Power folks. But I should give an example of a current difference between lock and acquire, and just to spread the blame, I will pick on an architecture other than Power. ;-) With lock acquisition, the following orders the access to X and Z: WRITE_ONCE(X, 1); spin_lock(&my_lock); smp_mb__after_lock(); r1 = READ_ONCE(Z); But if we replace the lock acquisition with a load acquire, there are no ordering guarantees for the accesses to X and Z: WRITE_ONCE(X, 1); r2 = smp_load_acquire(&Y); smp_mb__after_lock(); // Yeah, there is no lock. ;-) r3 = READ_ONCE(Z); There -is- ordering between the accesses to Y and Z, but not to X and Z. This is not a theoretical issue. The x86 platform really can reorder the access to X to follow that of both Y and Z. So the memory-model divergence between lock acquisition and acquire loads is very real in the here and now. Thanx, Paul
