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

[Andrew Haley]

On 03/09/2015 11:13 AM, David Holmes wrote:
> 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 compare 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.

No, it doesn't, but there is no reason that the Unsafe API should
provide stronger guarantees than the public APIs, and to do so would,
to quote Hans Boehm, be "too strong in ways that everybody pays for,
but that only benefit racy programs and experts who should know
better."

Andrew.