[concurrency-interest] Unsafe.getAndAddLong

Andrew Haley 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
x86.

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.

Andrew.


More information about the Concurrency-interest mailing list