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 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
>> processors?
> 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.)

I agree that doing something significantly more expensive on the
initialization path is worth it if we can avoid doing anything on the
non-initialization path.

For people who missed the original discussion on IRC, consider the
Double-Checked Locking Pattern:

if (!initialized)
    if (!initialized)
        initialize ();
        memory_barrier(); // force serialization on all CPUs
        initialized = true;

On Alpha we need a second memory barrier, i.e.

  read_memory_barrier ();

because a memory barrier on one CPU does not invalidate the cache on
another CPU, so once we see that initialized is set we need to force
serialization of reads so that when we go to access the controlled object
we don't see out-of-date data.

>From what people are saying, it sounds like on PPC, 'sync' does invalidate
speculative loads on other CPUs, whereas 'lwsync' does not.

On ia64, does a release barrier have the desired semantics, or do we need a
full barrier?

I would like the various port maintainers to let me know what
instruction(s) I should use for the memory barrier, or none if reads and
writes are always in-order.


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