[concurrency-interest] Realistic expectations of AtomicLongFieldUpdater

Carl Mastrangelo notcarl at google.com
Tue Sep 19 16:35:15 EDT 2017


If they are using different locks, wouldn't that imply that reads of a
volatile field might not see all published updates, since the updater might
acquire a different lock  (which would be in violation of the JMM) ?

On Mon, Sep 18, 2017 at 3:47 PM, Alex Otenko <oleksandr.otenko at gmail.com>
wrote:

> I reckon that statement is a permission to implement the Field Updaters
> using synchronized methods. That way you can guarantee individual Updaters
> behave atomically, but can’t guarantee atomicity of compare-and-set with
> respect to the other accesses, and cannot guarantee the Updaters behave
> atomically, if more than one instance is used - because they may be using
> different locks.
>
> Typically you need only one static final Field Updater, so the problem
> does not arise in practice.
>
> Alex
>
>
> On 18 Sep 2017, at 21:53, 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 <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?
> _______________________________________________
> Concurrency-interest mailing list
> 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/20170919/882d0c75/attachment-0001.html>


More information about the Concurrency-interest mailing list