[parisc-linux] Re: [parisc-linux-cvs] linux-2.6 jejb

[John David Anglin]

> On Wed, Aug 18, 2004 at 10:12:55AM -0400, James Bottomley wrote:
> > It's not a gcc *memory* barrier.
> > That means gcc is free to load a
> > memory reference before the spin lock and then use it after.
> 
> Wait...what you just described sounds like the toolchain was reordering
> instructions (which happen to access memory). memory barrier to
> me means we tell both HW to not re-order in certain ways (eg acquire,
> release semantics for ia64) *AND* we tell gcc to not re-order
> instructions around these memory barriers.

I'm far from an expert on this but I believe that gcc C will reorder
memory accesses for better scheduling if it can prove that the accesses
don't alias each other.  Thus, asm's have to be explicit regarding
the memory that they affect, and memory barriers may be needed around
critical regions.  3.3 and later are more aggressive than earlier
versions in this regard.

Dave
-- 
J. David Anglin                                  dave.anglin at nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)