[concurrency-interest] Realistic expectations of AtomicLongFieldUpdater

Carl Mastrangelo notcarl at google.com
Tue Sep 19 16:33:05 EDT 2017


I left publishing out on purpose, though the non static field updater was a
typo.

The origin of my question was if I needed to use the updater for field
initialization.   The javadoc implies yes, but it feels incorrect.

On Mon, Sep 18, 2017 at 1:53 PM, David Holmes <davidcholmes at aapt.net.au>
wrote:

> The issue is with atomicity not visibility. The volatile semantics of the
> field ensure visibility provided the Foo instance is not published during
> construction. Your example doesn’t show how the Foo instance is published.
> (And your updater reference would normally be a static).
>
>
>
> The atomicity caveat is just to account for potential interactions between
> raw updates and updates via the field updater. Though to be honest I’m
> having trouble recalling exactly what the issue is.
>
>
>
> David
>
>
>
> *From:* Concurrency-interest [mailto:concurrency-interest-
> bounces at cs.oswego.edu] *On Behalf Of *Carl Mastrangelo
> *Sent:* Tuesday, September 19, 2017 3:57 AM
> *To:* concurrency-interest at cs.oswego.edu
> *Subject:* [concurrency-interest] Realistic expectations of
> AtomicLongFieldUpdater
>
>
>
> 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/20170919/3273fc73/attachment.html>


More information about the Concurrency-interest mailing list