atom feed9 messages in edu.oswego.cs.concurrency-interestRe: [concurrency-interest] Using Atom...
FromSent OnAttachments
Ariel WeisbergFeb 13, 2013 12:41 pm 
Vitaly DavidovichFeb 13, 2013 12:51 pm 
Ariel WeisbergFeb 13, 2013 1:45 pm 
Vitaly DavidovichFeb 13, 2013 2:15 pm 
Aaron GrunthalFeb 13, 2013 7:37 pm 
Chris DennisFeb 14, 2013 8:15 am 
Ariel WeisbergFeb 14, 2013 8:56 am 
Vitaly DavidovichFeb 14, 2013 9:31 am 
Nathan ReynoldsFeb 14, 2013 9:41 am 
Subject:Re: [concurrency-interest] Using Atomic*FieldUpdater to remove indirection
From:Chris Dennis (cden@terracottatech.com)
Date:Feb 14, 2013 8:15:16 am
List:edu.oswego.cs.concurrency-interest

My understanding is that doing that is not technically (per the JDK spec) safe.
The updaters don't guarantee atomicity of their changes with respect to other
mutations. On Hotspot I think you can only see this behavior for
AtomicLongFieldUpdater when the underlying hardware lacks an 8 byte
compare-and-swap (which obviously makes sense).

On Feb 13, 2013, at 10:37 PM, Aaron Grunthal wrote:

Btw, Atomic*Updaters are not entirely equivalent to raw volatile/CAS accesses
due to a bunch of security checking they do. Especially when security domains
are used or the Updater's target class has subclasses then it has to do some
checks that the JVM cannot optimize away. So if every ounce of performance
counts you probably should do volatile reads and writes to the field handled by
the updater directly and only use it for CAS. And as last resort there's also
Unsafe, but there usually are bigger fish to fry before you get to that point.

On 13.02.2013 21:41, Ariel Weisberg wrote:

Hi,

Does it make sense to use Atomic*FieldUpdater to remove the indirection overhead of an AtomicLong and AtomicReference? Similarly, does it make sense to use Atomic* to create indirection in order to avoid false sharing?