Messages in this thread | | | Subject | Re: futex atomic vs ordering constraints | From | Davidlohr Bueso <> | Date | Fri, 28 Aug 2015 18:33:06 -0700 |
| |
On Wed, 2015-08-26 at 20:16 +0200, Peter Zijlstra wrote: > Of course, if anything else prior to futex_atomic_op_inuser() implies an > (RCsc) RELEASE or stronger the primitive can do without providing > anything itself. > > This turns out to be the case, a successful get_futex_key() implies a > full memory barrier; recent: 1d0dcb3ad9d3 ("futex: Implement lockless > wakeups").
Hmm while it is certainly true that get_futex_key() implies a full barrier, I don't see why you're referring to the recent wake_q stuff; where the futex "wakeup" is done much after futex_atomic_op_inuser. Yes, that too implies a barrier, but not wrt get_futex_key() -- which fundamentally relies on get_futex_key_refs().
> > And since get_futex_key() is fundamental to doing _anything_ with a > futex, I think its semi-sane to rely on this.
Right, and it wouldn't be the first thing that relies on get_futex_key() implying a full barrier.
| |