Messages in this thread | | | Date | Wed, 2 Sep 2015 14:18:53 -0700 | Subject | Re: futex atomic vs ordering constraints | From | Linus Torvalds <> |
| |
On Wed, Sep 2, 2015 at 10:00 AM, Peter Zijlstra <peterz@infradead.org> wrote: > > So I'm reading that code like: > > MB > [RmW] ret = *val += i > > > So what is stopping later memory ops like: > > [R] a = *foo > [S] *bar = b > > From getting reordered with the RmW, like: > > MB > > [R] a = *foo > [S] *bar = b > > [RmW] ret = *val += i
So I do agree that for the atomic futex operation to be usable for locking (which I think we all agree is a primary objective), the futex write operations have to work both as acquire and release operations, which basically means that it has to be both an acquire _and_ release op.
That said, I'm not sure it really needs to be a full memory barrier on both sides, and in particular, I'm not sure it needs to be a memory barroer for the surrounding *kernel* operations.
So I do suspect that adding full smp_mb()'s on both sides is not necessarily required for architectures, because there are often serialization guarantees at kernel entry/exit.
So I think we could possibly relax the requirements (and document this very clearly) to say that the futex operation must be totally ordered wrt any other _user_space_ accesses by that thread. I suspect a lot of architectures can then say "we may be very weakly ordered, but kernel entry/exit implies enough synchronization that we do not need any futher memory barriers".
For example, on x86, the locked instructions are obviously already sufficiently strong, but even if they weren't, kernel entry/exit is documented to be a serializing instruction (which is something insanely much stronger than just memory ordering). And I suspect there are similar issues on a lot of architectures where the memory ordering is done by the core, but the cache subsystem is strongly ordered (ie saen good SMP systems - so it sounds like tile needs the smp_mb()'s, but I would almost suspect that POWER and ARM might *not* need them).
Linus
| |