[concurrency-interest] Unsafe.getAndAddLong

Andrew Haley aph at redhat.com
Thu May 22 10:14:03 EDT 2014


How does getLongVolatile help the first read of 'v' to be up to date?
HotSpot emits an acquire barrier after reading 'v'.

On 05/22/2014 03:10 PM, Arcadiy Ivanov wrote:
> (1)To increase the chance that the first CAS will succeed.
> (2)To ensure that both 32bit words of a 64bit long are read atomically.
> 
> Otherwise there is a pretty good chance the first CAS will fail due to 
> 'v' either not being up-to-date or being nonsensical due to non-atomic 
> read of non-volatile longs and doubles.
> 
> On 2014-05-22 09:55, Andrew Haley wrote:
>> More memory model mysteries:
>>
>> Why do we use getLongVolatile here?  It'll be a load followed by an
>> acquire barrier.  But compareAndSwapLong is in effect a full barrier
>> anyway, so what's the point of using getLongVolatile?
>>
>>      public final long getAndAddLong(Object o, long offset, long delta) {
>>          long v;
>>          do {
>>              v = getLongVolatile(o, offset);
>>          } while (!compareAndSwapLong(o, offset, v, v + delta));
>>          return v;
>>      }
>>
>> Andrew.




More information about the Concurrency-interest mailing list