[concurrency-interest] Realistic expectations of AtomicLongFieldUpdater

Carl Mastrangelo notcarl at google.com
Wed Sep 20 21:31:28 EDT 2017


I still don't understand.  I have included a copy of the javadoc I am
reading:

"""
Note that the guarantees of the 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 compareAndSet
 and set on the same updater.
"""

So here is my reasoning:

1.  Modifications of a variable using the updater are atomic if and only if
using set() or compareAndSet()
2.  Volatile variable initialization is not done using the set() or
compareAndSet()
3.  Therefore,  compareAndSet is not atomic.

The conclusion seems absurd, but follows the javadoc.  What am I missing?




On Tue, Sep 19, 2017 at 1:40 PM, David Holmes <davidcholmes at aapt.net.au>
wrote:

> I don’t agree the Javadoc implies that. As I said the issue is atomicity
> not visibility – the field is volatile. At initialization you have not
> published the instance and so atomicity is not an issue (not that it would
> generally be an issue anyway – all loads and stores have to be atomic as it
> is volatile).
>
>
>
> Cheers,
>
> David
>
>
>
> *From:* Carl Mastrangelo [mailto:notcarl at google.com]
> *Sent:* Wednesday, September 20, 2017 6:33 AM
> *To:* dholmes at ieee.org
> *Cc:* concurrency-interest at cs.oswego.edu
> *Subject:* Re: [concurrency-interest] Realistic expectations of
> AtomicLongFieldUpdater
>
>
>
> 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/20170920/7b7e53f1/attachment.html>


More information about the Concurrency-interest mailing list