This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: should sync builtins be full optimization barriers?


> You need fences on x86 to implement Petterson or Dekkar spin locks but
> only because they involve write-read ordering to different memory
> locations (I'm mentioning those spin lock algorithms because they do
> not require locked memory accesses).  Write-write, read-read and for
> the same location write-read ordering are guaranteed by the processor.
>  Same for coherency which is a looser property.
>
> However, accesses in the those spin lock algorithm are definitely
> _not_ relaxed; not all of them, at least.
>
> > No that's false. Even on systems with nice memory models, such as x86
> > and SPARC with a TSO model, you need a fence to avoid that a write-load
> > of the same location is forced to make it all the way to coherent memory
> > and not forwarded directly from the write buffer or L1 cache.
>
> Not sure about SPARC, but this is definitely false on x86.

My understanding is that SPARC is on par with x86 here.  In particular, I don't 
think that accesses to the same location can be ordered differently depending 
on the processor.  That admittedly isn't very clear in the V8 manual, but much 
more in the V9 manual.  Quoting it:

"The order of memory operations observed at a single location is a total order 
that preserves the partial orderings of each processorâs transactions to this 
address. There may be many legal total orders for a given programâs execution"

-- 
Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]