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

[David Holmes]

On 5/07/2016 10:46 PM, Andrew Haley wrote:
> 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.

Right - ordering, not visibility.

David

> Andrew.
>