On Fri, Nov 22, 2013 at 10:26:32AM -0800, Paul E. McKenney wrote: > The real source of my cognitive pain is that here we have a sequence of > code that has neither atomic instructions or memory-barrier instructions, > but it looks like it still manages to act as a full memory barrier. > Still not quite sure I should trust it... Yes, this is something that puzzles me too. That said, the two rules that: 1) stores aren't re-ordered against other stores 2) reads aren't re-ordered against other reads Do make that: STORE x LOAD x form a fence that neither stores nor loads can pass through from either side; note however that they themselves rely on the data dependency to not reorder against themselves. If you put them the other way around: LOAD x STORE y we seem to get a stronger variant because stores are not re-ordered against older reads. There is however the exception cause for rule 1) above, which includes clflush, non-temporal stores and string ops; the actual mfence instruction doesn't seem to have this exception and would thus be slightly stronger still. Still confusion situation all round. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>