[concurrency-interest] Realistic expectations of AtomicLongFieldUpdater

Carl Mastrangelo notcarl at google.com
Mon Sep 18 13:56:38 EDT 2017


Hi concurrency-interest,

The classes AtomicLongFieldUpdater, AtomicReferenceFieldUpdater,
and AtomicIntegerFieldUpdater all have the same ominous comment at the top:

 * <p>Note that the guarantees of the {@code compareAndSet}
 * method in this class are weaker than in other atomic classes.
 * Because this class cannot ensure that all uses of the field
 * are appropriate for purposes of atomic access, it can
 * guarantee atomicity only with respect to other invocations of
 * {@code compareAndSet} and {@code set} on the same updater.


I am not sure how the Java memory model describes what happens to field
updaters, especially in regards to class initialization.  For example
consider the following:


class Foo {
  AtomicIntegerFieldUpdater<Foo> updater =
AtomicIntegerFieldUpdater.newUpdater(Foo.class,
"field");
  private volatile int field = 1;

  public void bar() {
    updater.compareAndSet(this, 1, 2);
  }
}

If two threads try to access field:

T1: final Foo f = new Foo();
T2: f.bar();

Is is guaranteed that subsequent reads of field will be 2?   From the docs
it implies that it may fail, since field was not initialized using
updater.set().  It my reading correct?


After talking to Martin Buccholz, it seems like even reads should be done
using the updater, but doesn't this violate the semantics of volatile?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170918/e6437e91/attachment.html>


More information about the Concurrency-interest mailing list