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.
