Unasafe.putOdered -> Unsafe.releasePut

[David Holmes]

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?

>> The implementation provides a stronger barrier than what is
>> required. Depending on your perspective either putOrdered captures
>> the right "lazySet" semantics but happens to be implemented using
>> stronger ones (and that implementation might be relaxed in the
>> future); or putOrdered is really intended to be release_store_fence
>> (and so could be renamed accordingly) and if you want to implement
>> true lazySet semantics then you have to define a new Unsafe API to
>> capture that.
>
>> Conversely if you need release_store_fence then you either define an
>> API that always provide it, or use an existing one (in this case it
>> is a normal volatile field write).
>
> Doug sez:
>
> << There are three basic strengths of write: Relaxed (normal),
> releasing, and SC volatile. I got talked into naming the second
> releasing version "lazySet" which is confusing enough, but compounded
> by the almost equally odd internal unsafe name "ordered".
>
> << These should be less confusing in JDK9 when we provide more uniform
> enhanced-volatile support. >>

Then there may indeed be hope for reconciling the different names.

Thanks,
David

> Andrew.
>