[cpp-threads] modes, interlude

[Doug Lea]

Boehm, Hans wrote:
> -
> 
>>From: Doug Lea
>>
>>If we are going to do this, is there any reason not go all 
>>the way and have four flavors of explicit barrier functions 
>>in the atomic classes and not bother adding modes to load, store etc?
>>
> 
> If I understand this correctly, there are two issues:
> 
> 1) Load(x, acquire) is weaker and much cheaper than load(x);
> full_barrier
> on many architectures, and load(x); acquire_barrier is nonsensical.
> (The load(x) can move after the barrier, which is not what you want.)
> 

But If I were a compiler implementor, the way I would process
these, regardless of superficial syntax, is to represent
loads/stores and reordering constraints separately, and then use a
matcher to possibly combine and issue instructions in the best way for a
given platform. (At least one JVM agrees with me that this is the best
strategy :-). So I think the only benefit of combined versions
for compilers is short-term, until they do things like this.

> 2) (Sorry about the Java terminology.) I'm not sure
> we've decided whether happens-before edges exist
> only between synchronizations on the same variable, or between any
> two synchronizations.  I think only the latter works with barriers.

Right. This is a bit messy, because storeLoad barriers
in particular exist only to inhibit reading values from write buffers
(possibly along with related snooping). If you express these things
with qualifiers rather than modes, compilers can in principle
eliminate those they can see are unnecessary because no such
written variables will be read. Or even more cleverly, model the
write buffer, so as to eliminate those that protect data read
further in the future than can be buffered. No JVM does such
optimizations, and it seems unlikely to be worthwhile doing so,
but itis even harder to do using modes than relying on properties of
variables.



-Doug