This is the mail archive of the
mailing list for the GCC project.
Re: More on memory barriers
- From: Jason Merrill <jason at redhat dot com>
- To: Geoffrey Keating <geoffk at apple dot com>
- Cc: gcc at gcc dot gnu dot org, Benjamin Kosnik <bkoz at redhat dot com>, Richard Henderson <rth at redhat dot com>, David Edelsohn <dje at watson dot ibm dot com>, Jason Merrill <jason at redhat dot com>
- Date: Wed, 15 Sep 2004 02:22:03 -0400
- Subject: Re: More on memory barriers
- References: <email@example.com><E6F54AAC-069E-11D9-B175-0030657EA24A@apple.com>
On Tue, 14 Sep 2004 15:39:12 -0700, Geoffrey Keating <firstname.lastname@example.org> 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.)
I agree that doing something significantly more expensive on the
initialization path is worth it if we can avoid doing anything on the
For people who missed the original discussion on IRC, consider the
Double-Checked Locking Pattern:
memory_barrier(); // force serialization on all CPUs
initialized = true;
On Alpha we need a second memory barrier, i.e.
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
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.