[cpp-threads] out-of-thin-air results, depndency-based orderingagain.

[Doug Lea]

Peter Dimov wrote:
> 
> So load_relaxed is 
> allowed to be delayed more and as a result, it can see a "more current" 
> value than load_acquire, if my understanding is correct. :-)
> 

I should have been more careful saying what you get.
It's a little messy though...

On any standard MP, any given read will return a value that is
either the last write by current processor (i.e., a "snooped"
value) or the last write committed in the global per-variable
total order.

The proposed difference between load_acquire and load_relaxed is that
for load_relaxed, you do not have any further promises of the value
being causally consistent, even wrt the current thread's instruction
stream. Except that you must retain the minimal guarantee
that the value is per-variable monotonic (i.e., will not back up
in the per-variable commit stream.) That's why it is conceivable
(but very doubtful) that some platforms would need some sort of
barrier to avoid doing the wrong thing with a sequence of
load_relaxed's to the same variable. (This form of "self
consistency" is discussed at http://www.cl.cam.ac.uk/~kaf24/mem.txt).

I think you are right that the net effect is that a load_relaxed
can be more eager, returning a value that will become the
most recently globally committed write further into the future.
It's hard to characterize exactly what happens in this way though,
because the act of performing such reads may change what threads
write or when they do so.

Note that this approach (like CCCC etc)  relies on infiltrating
models with the idea that they apply only to standard cache-coherent
machines (i.e., all commodity MPs). This is in part due to my
inability to imagine what a load_relaxed might otherwise mean.
And as an implicit corollary, I think that if people want models
and APIs that apply to more loosely-coupled clusters or systems
with odd NUMA rules, then there ought to be a separate message-passing
model and APIs. But these are arguably outside scope of this working
group anyway.


-Doug