[cpp-threads] [Fwd: [Javamemorymodel-discussion] MSDN on Memorymodels]

[Boehm, Hans]

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