From: "Chris Friesen" <cfriesen@xxxxxxxxxx> Date: Mon, 25 Jan 2010 12:53:32 -0600 > > Someone asked a question on comp.programming.threads about memory > barriers, which led me to the discovery that glibc and the kernel use > different semantics for memory barriers on sparc64 (and maybe sparc too, > didn't check). > > The kernel uses: > > read : LoadLoad > write : StoreStore > > This matches my understanding of the behaviour of other architectures as > well. I got confused when I saw that glibc (as of 2.8 at least) uses: > > read: LoadLoad | LoadStore > write: StoreLoad | StoreStore > > I'm curious about the difference. Could someone explain why glibc uses > additional restrictions and the kernel doesn't? The kernel knows some things about what ordering modes it will ever operate in (I'm referring to the current memory model as is programmed into the %pstate register), and the details of all existing sparc64 chips. So it can elide several kinds of barrier specifiations. GLIBC could do it too, at least under Linux, but to be "fully Sparc V9 compliant" it needs to use the full barriers. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
