aph at redhat.com
Thu May 22 14:01:30 EDT 2014
On 05/22/2014 06:14 PM, Arcadiy Ivanov wrote:
>> This argument is a strange combination of pragmatic efficiency
>> concerns and abstract language semantics.
> It was not an argument, it was an answer.
OK, it's a strange answer, then. :-)
> Your original question was "why is it there", not whether it's THE
> optimal implementation on all architectures. :)
I confess that the word-tearing argument never occurred to me. I've
been working in the 64-bit world for so long that I'd forgotten about
that. So, I can see why a volatile read may be a good idea on 32-bit
However, I had to question the explanation that volatile prevents a
stale value from being read because it doesn't do that on any
architecture of which I'm aware.
And it's worth pointing that out here, surely.
> Both Doug and myself provided you with several rationale in terms of JMM.
>> I don't think that word-tearing matters here: all it will do in the
>> odd chance that it occurs is cause a retry.
> Hence my answer: no matter the three reasons, the worst case is your CAS
> will fail the first time (unless another CAS intervenes again, ad
> infinitum). How bad the CAS failure is depends on the architecture.
> That said, I believe Unsafe.getAndAddLong is an intrinsic in Java 8 and
> 9 and will, barring any -XX options to the contrary, result in an
> 'inline_unsafe_load_store(T_LONG, LS_xadd);' further resulting in LOCK
> XADDL on X86, so it's a non-issue to begin with for X86 architectures.
> You might be interested in a similar intrinsic for ARMv8 if one isn't
> already available and could be implemented.
Sure, I will do that. I was just trying to understand why the Java
version is the way it is.
More information about the Concurrency-interest