Unasafe.putOdered -> Unsafe.releasePut

[Andrew Haley]

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.

> 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. >>

Andrew.