memory barriers on sparc

memory barriers on sparc

[Chris Friesen]

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?

Thanks,

Chris

Re: memory barriers on sparc

[David Miller]

From: "Chris Friesen" <cfriesen@nortel.com>
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.