On Thu, 26 Feb 2015 14:47:54 +0100 Peter Zijlstra <pet...@infradead.org> wrote:
> > Thinking about this more, is it because a wmb just forces the CPU to > > write everything before this before it writes anything after it. That > > is, the writes themselves can happen at a much later time. Does a plain > > mb() work the same way if there are no reads required? > > No, neither smp_wmb nor smp_mb are required to flush the store buffers. Heh, that's what I said :-) "That is, the writes themselves can happen at a much later time." > > The only thing barriers do is guarantee order, this can be done by > flushing store buffers but it can also be done by making sure store > buffers flush writes in the 'right' order. > > Nor does an rmb help anything with ordering against a possible store > buffer flush. Again rmb only guarantees two loads are issued in that > particular order, it doesn't disallow the CPU speculating the load at > all. Yep understood. > > What about using atomic_t? > > > > Note, my latest code doesn't have any of this, but I just want to > > understand the semantics of these operations a bit better. > > Nope, atomic_t doesn't help here either. Atomics only make sure the RmW > cycle is atomic. Crummy. ;-) > > Note that even if wmb or mb did flush the store buffer, you would still > have a race here. Oh, it wasn't that I meant to remove the race. I was just trying to make that race smaller. But this is all academic now, as my last version doesn't do any of this. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
