[concurrency-interest] Realistic expectations of AtomicLongFieldUpdater

Carl Mastrangelo notcarl at google.com
Wed Sep 20 21:33:30 EDT 2017

What would be the difficulty be in defining the behavior in the JMM?  Or
has this already been done because of VarHandles?

On Tue, Sep 19, 2017 at 11:58 PM, Alex Otenko <oleksandr.otenko at gmail.com>

> The updates should be observable by all threads, because they are volatile
> accesses inside, but the statement about “the same updater” means that
> atomicity of compareAndSet may be implemented through means other than an
> intrinsic CAS with/or global lock - all other accesses are atomic by JMM.
> For example, a store to the volatile may interleave with compareAndSet and
> you may observe “non-intuitive results”, unless you are using the set
> method on the same updater.
> (“non-intuitive” means “the execution that isn’t observable with atomic
> compareAndSet”, but JMM doesn’t have a definition of compareAndSet, so you
> can’t call it “broken” so easily)
> Alex
> On 19 Sep 2017, at 21:35, Carl Mastrangelo <notcarl at google.com> wrote:
> 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-b
>> ounces 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/20170920/659f88db/attachment-0001.html>

More information about the Concurrency-interest mailing list