[concurrency-interest] Suggestion: .hardGet() for atomicvariables

Nathan Reynolds nathan.reynolds at oracle.com
Mon Jan 23 10:55:55 EST 2012


I realize that this discussion has been theoretical.  I would like to 
point out one small gotcha.  Ideally, getAndAdd(0) would compile down to 
x86's "lock xadd" instruction.  But, HotSpot doesn't do that at the 
moment.  The current implementation is as what you see in the JDK Java 
code.  I have included it below.  So, compareAndSet(x, x) would actually 
perform better than getAndAdd(0).  This is because getAndAdd(0) executes 
a few more instructions and it could loop a few times under contention.

   public int getAndAdd(int delta)
   {
     while (true)
     {
       int i = get();
       int j = i + delta;
       if (compareAndSet(i, j))
         return i;
     }
   }

There is an enhancement request to make getAndAdd a compiler intrinsic 
on x86.  The method would be replaced with "lock xadd".  However, this 
won't help for processors that don't have an atomic add instruction 
(e.g. Sparc).  I have asked the Sparc team for an atomic add 
instruction.  I am not sure if it will be done.

Nathan Reynolds 
<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> | 
Consulting Member of Technical Staff | 602.333.9091
Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology

On 1/20/2012 8:45 PM, Vitaly Davidovich wrote:
>
> MOV + compiler barrier wouldn't be the right transformation on x86 
> because that wouldn't be the same thing as a volatile write (I.e. 
> store-load fence), it would be analogous to just store-store.  I think 
> a cas(x, x) instead of getAndAdd(0) would work and makes sense, 
> although I wonder if compilers care about such special cases - the cas 
> will already possibly incur a perf penalty so the extra add 
> instruction is probably insignificant to optimize.
>
> Vitaly
>
> Sent from my phone
>
> On Jan 20, 2012 8:37 PM, "Boehm, Hans" <hans.boehm at hp.com 
> <mailto:hans.boehm at hp.com>> wrote:
>
>     > From: Raph Frank [mailto:raphfrk at gmail.com
>     <mailto:raphfrk at gmail.com>]
>     >
>     > Thanks for the info.
>     >
>     > On Fri, Jan 20, 2012 at 11:10 AM, Ruslan Cheremin
>     <cheremin at gmail.com <mailto:cheremin at gmail.com>>
>     > wrote:
>     > > long seq = sequence.get();
>     > > ...some reading...
>     > > if( !sequence.CAS(seq, seq) ){
>     > >   //...approach failed -> retry
>     > > }
>     > >
>     > > So, from my point of view, if CAS failed -- we shouldn't actually
>     > care
>     > > about it's ordering semantic (although it was interesting to
>     know --
>     > > thanks, David -- what ordering does not depend on
>     success/fail). If
>     > > CAS succeeded -- it does required guarantee anyway. Am I wrong
>     > > somewhere here?
>     >
>     > Ahh right, that is better than
>     >
>     > if (sequence.getAndAdd(0) != seq) {
>     > <retry>
>     > }
>     >
>     > Anyway, thanks all for the info.
>
>     Thanks for the corrections and clarifications.  It does look like
>     we should essentially view CAS as always performing a volatile
>     store, possibly of the original value.
>
>     It seems to me that the trade-off between CAS and getAndAdd here
>     is highly implementation dependent.  Clearly if getAndAdd(0) is
>     implemented in terms of CAS(x,x), CAS is faster.  I suspect either
>     could in theory be optimized to a plain old MOV + compiler
>     constraints on x86.
>
>     Hans
>
>
>
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120123/62024ddc/attachment.html>


More information about the Concurrency-interest mailing list