Unasafe.putOdered -> Unsafe.releasePut

[Andrew Haley]

On 05/03/15 11:37, David Holmes wrote:
> On 5/03/2015 7:16 PM, Andrew Haley wrote:
>> On 05/03/15 00:49, David Holmes wrote:
>>> On 2/03/2015 9:54 PM, Paul Sandoz wrote:
>>>>
>>>> On Mar 2, 2015, at 12:07 PM, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>>> Hi Paul,
>>>>>
>>>>> This is more a question for core-libs and the users of this Unsafe API.
>>>>
>>>> I wanted to check here first because of work done in [1] and because this is where there is most experience with the Unsafe implementation. I don't want to change the semantics of existing Unsafe methods.
>>>>
>>>> Note that the VarHandle work will expose using release/acquire names, where the former implementation defers to Unsafe.putOrdered*, and the later to relaxed plus explicit load fence.
>>>
>>> The Unsafe API naming tends to be done by whomever is defining the
>>> public API that uses it (eg. Doug Lea for j.u.c). The implementation of
>>> the Unsafe API then has to map through to whatever the VM provides. So
>>> given there are three layers you either match the first two or the last
>>> two but you can rarely make all three the same.
>>>
>>> So for example, j.u.c.atomic lazySet is defined as providing:
>>>
>>>    *   <li> {@code lazySet} has the memory effects of writing (assigning)
>>>    *   a {@code volatile} variable except that it permits reorderings with
>>>    *   subsequent (but not previous) memory actions that do not themselves
>>>    *   impose reordering constraints with ordinary non-{@code volatile}
>>>    *   writes.
>>>
>>> and is implemented by a call to Unsafe.putOrdered, which in turn is
>>> implemented by doing a full volatile write, which is
>>> OrderAccess::release_store_fence.
>>
>> A volatile write is stronger than just a release_store_fence.
> 
> release_store_fence is:
> 
> loadstore|storestore
> <store>
> loadload|loadstore|storestore|storeload
> 
> what do you think is missing?

My apologies.  I'd forgotten that release_store_fence is rather
confusingly named: it's not a release-store fence, it's a release
store followed by a full fence.

It's clear from Doug's comment that this implementation of lazySet is
too strong: it was intended to be a releasing store.

Andrew.