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

[Vance Morrison]

Below are some comments from Han's questions

> > 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.


It is my understanding from talking with some Intel folks that the L1
cache of the intel IA64 processor is not coherent with the L2 cache
(which is kept coherent with respect to other processors).  However this
kind of information is typically hard insure accuracy.  The main point
however is that it takes extra effort to insure consistency, and this is
independent of the answer to what various processors actually do.  


> > 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.

I did not know that the PA-RISC was sequentially consistent.  That is
interesting.  

> > 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.

I agree that it should say 
> >   Reads and writes cannot move before entering a lock.
> >   Reads and Writes cannot move after exiting a lock.

Sigh.  



> > 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


I am afraid that I don't understand the issue Han's is bringing up here.

A more detailed description is in order.    Note that this last example
was the one that there was the most internal debate about whether we
could make rules that would actually allow it to work in the model.   It
would not surprise me to find a problem here.   I would be interested in
exploring the details.  

Vance


------------------------------------------------------------------------
---

-----Original Message-----
From: Herb Sutter 
Sent: Tuesday, September 13, 2005 6:56 PM
To: cpp-threads at decadentplace.org.uk; Vance Morrison
Subject: RE: [cpp-threads] [Fwd: [Javamemorymodel-discussion]
MSDNonMemorymodels]

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