[cpp-threads] C++ memory model

[Boehm, Hans]

> 
> Hans Boehm links to many such documents from 
> <http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/>.
> 
I'd be happy to link to it if you give me a URL.

Some more comments on the paper, after finally having gone through most of it:

2.1: I agree.  This is realy only an issue with the PLDI paper, not the standard.

2.2: (There were other comments on this as well.)  I'm not sure what the right answer is here.  A core question seems to be whether I can use memcpy to take a snapshot of a class object containing an atomic while nobody else is modifying it, and then safely examine at least other fields in the copy.  My assumption was that this was intended to work, and thus some mixed accesses are acceptable.  But I can see arguments both ways.

2.3: My interpretation of initialization semantics differs from what has been discussed here.  My assumption was that any initialization is treated as one or more ordinary stores that happen before the start of the main thread, and hence before the start of any thread (except for function-local statics, where we should already have explicit synchronization rules).  Thus initializatios aren't really special as far as the memory mode is concerned.  But it doesn't sound like we made that very clear.

2.4: I think the paper actually does talk about "data accesses", which is intended to preclude the atomic case.  It indeed erronesoulsy fails to mention the read case.

3.2: "Maximal length" would be a bit clearer.  The other possible interpretation
hadn't occurred to me, but given all the orderings here, I can see how it might be misinterpreted.

3.3: The note in 1.10p14 should be fixed.  I think it predates a lot of changes, and we somehow missed that update.  Although notes are not normative, and thus this isn't technically important, it is confusing, and misstates the intent.

3.5: The semantics of the switch statement are intended tobe the same as for the conditional.  In both cases the standard does not completely disallow r1 == r2 == 42, but it doscourages it (with a "should" statement in a note).  We're between a rock and a hard place here:

- We can hand wave a bit, as we chose to do.  The language is somewhat ill-defined in this obscure corner, which I suspect really doesn't matter.

- We could try to specify this precisely, where others failed.  If you wanted to do this really right, with the best possible optimizations, you end up with something similar, at least in spirit, to the Java causality rules.  We know that those are sifficiently messy that they have limited use.  And the current version has some weird, unintended consequences, which even the original JSR133 participants didn't expect.  Especially in retrospect, it's not clear that the added precision here would have bought us anything except a more confusing standard.

So the short answer is we know that this isn't 100% satisfactory, but I don't think anyone knows how to fix it.  And unlike in the Java case where it affects ordinary variables, few people are likely to care.

5: This touches on some other research problems.  Some of us have our doubts about non-memory_order_seq_cst operations, since they seem to be very hard to encapsulate in a library such that the higher level library operations themselves look sequentially consistent, though it can sometimes be done.  Lock implementations may be an instructive example.  If the lock interface is such that trylock() is either not there, or allows spurious failures, then a (spin)lock release can be implemented with a release store, and the result looks sequentially consistent to the client.  If you strengthen the specification to disallow spurious trylock() failures, then the release store "leaks" to the client, and the result becomes messy to describe.  This all seems quite subtle, and this is a really simple potential application.

I don't think we really have a "safe use" methodology for low-level atomics that generalizes observations like this.

Hans