[cpp-threads] [Fwd: [Javamemorymodel-discussion] MSDNonMemorymodels]

[Herb Sutter]

Hi Vance, looping you on a discussion Hans and others were having about
your article on lock-free programming. Hans' comments and questions
about memory model are below. I know it's PDC week so you may be in LA,
but if you have a chance feel free to chime in...

Herb


> -----Original Message-----
> From: Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk]
On
> Behalf Of Herb Sutter
> Sent: Tuesday, September 13, 2005 5:17 PM
> To: cpp-threads at decadentplace.org.uk
> Subject: RE: [cpp-threads] [Fwd: [Javamemorymodel-discussion]
> MSDNonMemorymodels]
> 
> Alexander wrote:
> >Regarding
> > "I am only guessing at the x86 memory model from observed behavior
on
> > existing processors."
> >[...links...]
> 
> It is easy to get approximations, but (alas) I don't know of any
> published spec or description that accurately describes what the
> hardware actually does. That includes Intel's spec. And it really is
> hard to get answers to detailed questions when you try to drill down.
> 
> Hans wrote:
> > Can anyone point me at the place in the C# or CLI spec where this is
> > specified?  I couldn't find it.
> 
> What we implemented is stronger than what's in the spec.
> 
> Hans, would you like me to forward your comments to Vance, or invite
him
> to join this discussion?
> 
> Herb
> 
> 
> > -----Original Message-----
> > From: Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk
> >
[mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk]
> On
> > Behalf Of Boehm, Hans
> > Sent: Tuesday, September 13, 2005 4:14 PM
> > To: cpp-threads at decadentplace.org.uk
> > Subject: RE: [cpp-threads] [Fwd: [Javamemorymodel-discussion] MSDN
> > onMemorymodels]
> >
> > Can anyone point me at the place in the C# or CLI spec where this is
> > specified?  I couldn't find it.
> >
> > According to the article, this essentially appears to be an X86-only
> (or
> > processor-consistent-only) memory model.  I don't see how it could
be
> > implemented efficiently on IA64 or PowerPC, for example.  I would
> > suspect it's not efficiently implementable on in-order processors
> (like
> > current SPARC TSO) either, but I don't understand it well enough to
> make
> > that claim.
> >
> > This article also seems to have a few bugs, the last one of which
> seems
> > serious:
> >
> > 1. The description of how SMP caches work is at least inconsistent
> with
> > my understanding.  AFAIK, few hardware caches allow inconsistent
> values
> > in different processor caches.
> >
> > 2. I believe PA-RISC multiprocessors are actually sequentially
> > consistent.  There does exist sequentially consistent hardware, but
> that
> > doesn't seem to be the trend.  And compilers are probably more of an
> > issue anyway.
> >
> > 3. The rules
> >
> >   The behavior of the thread when run in isolation is not changed.
> > Typically, this means that a read or a write from a given thread to
a
> > given location cannot pass a write from the same thread to the same
> > location.
> >   Reads cannot move before entering a lock.
> >   Writes cannot move after exiting a lock.
> >
> > seem way too weak to be useful.  It means that if we have (x, y
> > initially zero)
> >
> > Thread 1:
> > lock(l); x = 1; y = 1; unlock(l);
> >
> > Thread 2:
> > lock(l); r1 = y; r2 = x; unlock(l);
> >
> > then r1 = 1, r2 = 0 is an acceptable outcome.  Oops.  In fact, it
> seems
> > this really allows me to move all reads and writes out of the lock,
so
> > long as I can speculatively do the writes early.
> >
> > (But I did find that the standard doesn't really allow that.)
> >
> > 4.  At least the LazyInitClass2 example seems to be legal only with
a
> > very weird interpretation of the rules in which the ordering
> constraints
> > apply to program text instead of dynamically executed actions.  In
> > particular:
> >
> > "Reads can only move earlier in time, but never past a write to the
> same
> > memory location from the same thread."
> >
> > seems to apply if the right is textually there, but conditional, and
> not
> > executed?  The ordering of the reads of myValue and myValueInit
> matters
> > even, or particularly, if the initialization code is not executed,
and
> > hence there are no intervening writes.
> >
> > As a result there seem to be seemingly equivalent but textually
> > rearranged programs that are incorrect?  E.g. if I change the body
of
> > GetValue to an if-then-else with the return duplicated in both
> branches,
> > then the correctness depends on which branch textually comes first?
> >
> > Either I'm misunderstanding this, or something is still broken here
> ...
> >
> > Hans
> >
> > > -----Original Message-----
> > > From:
> > > Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk
> > > [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> > > .org.uk] On Behalf Of Doug Lea
> > > Sent: Tuesday, September 13, 2005 1:27 PM
> > > To: cpp-threads at decadentplace.org.uk
> > > Subject: [cpp-threads] [Fwd: [Javamemorymodel-discussion]
> > > MSDN on Memorymodels]
> > >
> > >
> > >
> > > Crossposting from JMM list (as a forward so you can see that
> > > JMM list address has changed.)
> > >
> > > -Doug
> > >
> > >
> >
> > --
> > cpp-threads mailing list
> > cpp-threads at decadentplace.org.uk
> > http://decadentplace.org.uk/mailman/listinfo/cpp-
> > threads_decadentplace.org.uk
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://decadentplace.org.uk/mailman/listinfo/cpp-
> threads_decadentplace.org.uk