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).
Hans
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120121/b682d91c/attachment.html>