[cpp-threads] [Fwd: [Javamemorymodel-discussion] MSDN onMemorymodels]

[Herb Sutter]

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