On Fri, Sep 27, 2013 at 08:17:50AM -0700, Paul E. McKenney wrote: > > Barriers are fundamentally about order; and order only makes sense if > > there's more than 1 party to the game. > > Oddly enough, there is one exception that proves the rule... On Itanium, > suppose we have the following code, with x initially equal to zero: > > CPU 1: ACCESS_ONCE(x) = 1; > > CPU 2: r1 = ACCESS_ONCE(x); r2 = ACCESS_ONCE(x); > > Itanium architects have told me that it really is possible for CPU 2 to > see r1==1 and r2==0. Placing a memory barrier between CPU 2's pair of > fetches prevents this, but without any other memory barrier to pair with.
Oh man.. its really past time to sink that itanic already. I suppose it allows the cpu to reorder the reads in its pipeline and the memory barrier disallows this. Curious.. does our memory-barriers.txt file mention this 'fun' fact? -- 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/
