RFR: JDK-8074578 Document memory visibility effects of some Unsafe methods

[David Holmes]

On 9/03/2015 7:27 PM, Andrew Haley wrote:
> On 09/03/15 00:34, David Holmes wrote:
>> On 7/03/2015 6:49 AM, Martin Buchholz wrote:
>>> A wee code review fer ya:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8074578
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Unsafe-CAS-spec/
>>
>> Sorry Martin but this is neither accurate nor meaningful. It isn't
>> accurate because the actual Atomic::cmpxchg operations have full
>> bi-directional fences, and in the long case if locking is used you get
>> locking related barriers not volatile access barriers.
>
> But the fact that an implementation is stronger than is strictly
> required has no bearing on the specification.  We've discussed this at
> some length on the concurrency-interest list, and the semantics of a
> volatile read followed by a volatile write (if the copmpare is
> successful) are what is required by the JMM.

But who is to say that is the specification for the Unsafe API? The 
public API's have a specification for what they provide to the 
programmer. On what basis are we assigning that same specification to 
Unsafe API? The Unsafe API has to meet the requirements of the public 
APIs that use it, but that doesn't  mean it necessarily should have the 
same specification as those APIs.

David

> Andrew.
>