[concurrency-interest] Unsafe.getAndAddLong

Doug Lea dl at cs.oswego.edu
Thu May 22 10:22:59 EDT 2014


On 05/22/2014 10:12 AM, 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.

Right. The second is the main reason. It could be relaxed at the
expense of more CAS misses. This might even be a good idea,
and worth contemplating, but seems marginal.

-Doug

>
> 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.
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



More information about the Concurrency-interest mailing list