[cpp-threads] A draft memory model paper

[Boehm, Hans]

I expect this is an issue that we need to discuss at the meeting for the
C++ model.

Herb's paper is a bit unclear about whether interlocked writes followed
by reads can be reordered.  (I think 3.3.2 says they can?)  Assuming
they can't, which I think is the intent, I agree that a fence is
required for stores on both X86 and IA64.  I think that means you take
100+ cycle hit on an interlocked store for at least some Pentium 4
variants.  Since you don't take the hit on a load, and I think it's
unlikely that future processors would share this feature, that may be
OK, at least for default behavior.  I don't know.

Hans


> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Peter Dimov
> Sent: Tuesday, August 08, 2006 3:50 AM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] A draft memory model paper
> 
> Herb Sutter wrote:
> > Peter wrote:
> >> How do you expect a compiler that follows this memory model to
> > translate:
> > [code with interlocked variables]
> >
> > Same as JSR-133 cookbook for Java volatile, no?
> 
> Yes indeed. :-)
> 
> > BTW, the paper uses "interlocked" simply to avoid the V-word, since 
> > "volatile" is a lightning rod even though this is similar 
> to Java and 
> > .NET volatile.
> >
> >> extern interlocked int x;
> >>
> >> void f()
> >> {
> >>     x = 1;
> >
> > On IA64, st.rel [x] = 1. On IA32 plain store + mfence is one way, I 
> > suppose?
> >
> >> }
> >>
> >> and:
> >>
> >> extern interlocked int y;
> >> extern void h();
> >>
> >> void g()
> >> {
> >>     if( y ) h();
> >
> > On IA64, ld.acq [y] = 1. On IA32 plain load, I suppose?
> >
> >> }
> 
> But if you later call f(); g(); in sequence, st.rel can be 
> reordered with ld.acq, and the MM doesn't allow that. So one 
> of the two needs an additional mf. On x86, plain load is 
> ld.acq and plain store is st.rel, but translating stores to 
> plain store + mfence would indeed impose a total order.
> 
> Unfortunately it can also impose a performance hit.
> 
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>