This is the mail archive of the 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: More on memory barriers

On 15/09/2004, at 2:29 PM, Jason Merrill wrote:

On Tue, 14 Sep 2004 15:39:12 -0700, Geoffrey Keating <> wrote:

On 14/09/2004, at 2:25 PM, Jason Merrill wrote:

Or is it the case on all of these targets that using a more heavyweight
barrier (i.e. sync on PPC) invalidates speculative loads on other

It's certainly the case on PPC.

(I would suggest using 'sync' on the initialization path rather than having
a 'lwsync' on both paths. Even though 'sync' is more expensive, I would
expect that the non-initialization path will be much more common.)

Can you point me to a reference for this behavior? I haven't been able to
find anything that talks about effects of synchronization primitives on
other processors.

The powerpc ISA spec doesn't actually document how processors communicate with each other; that's left for the specifications of individual buses, and AFAIK there's no publically available power4 or power5 bus spec (David may be able to correct me here).

only talks about the effects of the instruction on the processor which
executes it. I also note that the NPTL pthread_once implementation for PPC
includes an isync on the early exit path, as I was suggesting.

This could be correct, depending on what they have on the non-early-exit path, and the coherency status of user-space memory on linux. There are a bunch of options ranging from "the early exit path needs to do nothing to guarantee coherency" to "the early exit path must do all the work to guarantee coherency".

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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