RFR #2 (M) 8148146: Integrate new internal Unsafe entry points, and basic intrinsic support for VarHandles

[Andrew Haley]

On 05/07/16 13:17, David Holmes wrote:
> On 5/07/2016 7:09 PM, Andrew Haley wrote:
>> On 04/07/16 22:09, David Holmes wrote:
>>> Surely cmpxchg already ensures the store (if it happens) is visible in
>>> other threads - else the cmpxchg would not even operate correctly.
>>
>> No, it doesn't.  Semantically, the cmpxchg is no more than an atomic
>> operation on a single word: it has no other memory ordering effects.
>> If you want the store to be observed before some other memory access
>> you have to do something to make that happen.
> 
> You seem to be confusing ordering with visibility.

I hope not.

> The cmpxchg must be visible to other threads else cmpxchg can't
> function. But that doesn't imply any ordering constraints with
> anything before/after the cmpxchg.

Indeed not, but a volatile store -- the case I'm talking about -- is
supposed to be part of the total order.  So, the store must be
sequenced before any following volatile loads.  It makes no difference
whether the operation is a simple store or is a cmpxchg: we need the
trailing StoreLoad barrier.

Andrew.