[cpp-threads] modes, interlude

[Boehm, Hans]

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

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.
I think only the former is practical for a software DSM implementation.
I'm undecided as to whether that matters.  (If 10GB ethernet goes
mainstream at some point in the near future, I think the time
it takes to transfer a 4K page gets a lot closer to large machine
memory latencies than it has ever been before.  I have no idea how
this will play out by 2009.)

Hans