| Date | Tue, 11 Jun 2013 10:49:51 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH RFC ticketlock] v2 Auto-queued ticketlock |
| |
On Tue, Jun 11, 2013 at 10:35:53AM -0700, Linus Torvalds wrote: > Hmm. Something just struck me when reading this patch.. > > Our memory ordering semantics in our *current* locks are very very > subtle. We have just a "barrier()" between the > > inc.head = ACCESS_ONCE(lock->tickets.head); > if (inc.head == inc.tail) > break; /* success */ > > and the inside of the locked region. > > I think it's safe because of the new memory ordering semantics (loads > are in-order, and stores only move *down*), but there's not even a > comment about it. > > So let's at least comment the current locks before making them even > more complex and subtle..
Would it make sense to have something like an smp_tso() that was a compiler barrier for TSO systems (x86, s390, sparc, etc.) but that emitted the needed memory-barrier instruction for weakly ordered systems?
Seems to me to be easy to do, and helps describe the intent better.
Thanx, Paul
|