[cpp-threads] Temporal models

[Jeremy Manson]

Hi again,

Boehm, Hans wrote:
> 2) For atomic accesses, in C++ you don't get implicit ordering between
> two operations in a thread because one "causes" the other, except for
> the "depends on" relation, which is limited to atomic stores depending
> on loads.  This relation somewhat violates Jeremy's statement about
> defining dependence, except that it talks about dynamic dependence, and
> I think only in a case in which that makes sense.

This is what I was asking when I asked if "causal" meant something 
specific in this context - that we are not necessarily talking about all 
standard dependences.  This is good to know.  It has been a little while 
since I looked at the straw man.

> (This does prevent you from
> taking advantage of some dependence-based ordering constraints enforced
> by most hardware.  E.g. it slows down some variants of
> double-checked-locking on Itanium and PowerPC.  But as Jeremy pointed
> out, that quickly gets tricky due to compiler optimizations.)

My feeling about this issue in this context is that if you want to rely 
on a processor-specific ordering constraint, you really have to 
understand what your entire runtime - compiler and hardware - are doing 
to your code.  If your code is platform-specific, then you are all set here.

I also think that C and C++ programmers trying to write code that takes 
advantage of such things should already be aware of these issues.  This 
kind of code is not for the faint of heart.

> 
> 3) [I think this is what was meant.] There is an interesting question
> that Nick has pointed out before of whether communication through
> external actions implies a happens-before relationship.  If thread 1
> writes to a file, and thread 2 sees the result, does the write
> happen-before the read?  My impression is that Java leaves this
> underspecified, as does everything else.  The current C++ proposal
> currently has a vague statement about this, but I think this really
> needs to be pushed into the library spec.

Do you really want to do this for all IO, or do you want to do it on a 
case-by-case basis?  I can imagine situations in which you would not 
want to make that guarantee (for example, if the compiler can't identify 
a memory write as an IO operation).

					Jeremy