[cpp-threads] Alternatives to SC (reader cost of SC on JSR133)

[Doug Lea]

Raul Silvera wrote:
> cpp-threads-bounces at decadentplace.org.uk wrote on 01/29/2007 07:16:54 PM:
> 
>> Hans wrote:
>> Based on the JSR133 cookbook rules, I believe that atomic loads can be
>> cheap enough.  (You do need an expensive StoreLoad fence between an
>> atomic store and a load, and you usually don't have enough context to
>> determine whether that's an issue.  But the fence can be associated with
>> the store, keeping the load relatively cheap, aside from the "acquire
>> fence", which tends not to be that expensive.)  This leaves the issue as
>> to whether we can get hardware to guarantee that the JSR133 rules
>> actually guarantee SC, or only something weaker, which is being
>> discussed.
>>
> 
> To achieve SC, you need a StoreLoad fence not just between an atomic store
> and a load, but also between atomic loads. Otherwise the IRIW case fails.
> Doug, do you agree with that?
> 


Almost. The "SC issue" stems from:

When you use "reasonable" mappings for (Java)volatiles/(C++)atomics,
and compare best interpretations of platform specs vs
memory model specs, everything meshes except for the assertion
that you get SC. (CCCC serves as a non-hardware-specific
abstract model of what you get instead.)

But it becomes more interesting than this, because it is not
necessarily the case that you get SC even if you *do* place
the strongest kind of barrier available on a platform between
each load. Instead, SC may require the use of "confirming"
CAS or LL/SC for each load, which completely escapes all
notions of reasonableness for mappings.


-Doug