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

Boehm, Hans hans.boehm at hp.com
Sat Jan 21 00:38:58 EST 2012

I'm not sure.  Is there any legitimate Java code that could tell the difference?  An x86 load (MOV) can only be reordered with prior stores.   But I don't immediately see how  an observer thread could tell whether

x = ...
r1 = z.getAndAdd(0);

is reordered.  This would require more thought.  But I agree that it's not too likely that any compiler would try to specially optimize getAndAdd(0).


From: Vitaly Davidovich [mailto:vitalyd at gmail.com]
Sent: Friday, January 20, 2012 7:46 PM
To: Boehm, Hans
Cc: concurrency-interest at cs.oswego.edu; Ruslan Cheremin; Raph Frank; dholmes at ieee.org
Subject: Re: [concurrency-interest] Suggestion: .hardGet() for atomicvariables

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.


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.


Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu<mailto:Concurrency-interest at cs.oswego.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120121/b682d91c/attachment.html>

More information about the Concurrency-interest mailing list