Realistic expectations of AtomicLongFieldUpdater

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Realistic expectations of AtomicLongFieldUpdater

Carl Mastrangelo
Hi concurrency-interest,

The classes 
AtomicLongFieldUpdaterAtomicReferenceFieldUpdater, 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Realistic expectations of AtomicLongFieldUpdater

David Holmes-6

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:[hidden email]] On Behalf Of Carl Mastrangelo
Sent: Tuesday, September 19, 2017 3:57 AM
To: [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Realistic expectations of AtomicLongFieldUpdater

Alex Otenko
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 <[hidden email]> 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 [[hidden email]] On Behalf Of Carl Mastrangelo
Sent: Tuesday, September 19, 2017 3:57 AM
To: [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Realistic expectations of AtomicLongFieldUpdater

Carl Mastrangelo
In reply to this post by David Holmes-6
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 <[hidden email]> 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:[hidden email]] On Behalf Of Carl Mastrangelo
Sent: Tuesday, September 19, 2017 3:57 AM
To: [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Realistic expectations of AtomicLongFieldUpdater

Carl Mastrangelo
In reply to this post by Alex Otenko
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 <[hidden email]> 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 <[hidden email]> 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 [[hidden email]] On Behalf Of Carl Mastrangelo
Sent: Tuesday, September 19, 2017 3:57 AM
To: [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Realistic expectations of AtomicLongFieldUpdater

David Holmes-6
In reply to this post by Carl Mastrangelo

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:[hidden email]]
Sent: Wednesday, September 20, 2017 6:33 AM
To: [hidden email]
Cc: [hidden email]
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 <[hidden email]> 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:[hidden email]] On Behalf Of Carl Mastrangelo
Sent: Tuesday, September 19, 2017 3:57 AM
To: [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Realistic expectations of AtomicLongFieldUpdater

David Holmes-6
In reply to this post by Carl Mastrangelo

The field itself is volatile.

 

David

 

From: Carl Mastrangelo [mailto:[hidden email]]
Sent: Wednesday, September 20, 2017 6:35 AM
To: Alex Otenko <[hidden email]>
Cc: [hidden email]; [hidden email]
Subject: Re: [concurrency-interest] Realistic expectations of AtomicLongFieldUpdater

 

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 <[hidden email]> 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 <[hidden email]> 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 [[hidden email]] On Behalf Of Carl Mastrangelo
Sent: Tuesday, September 19, 2017 3:57 AM
To: [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

 

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Realistic expectations of AtomicLongFieldUpdater

Alex Otenko
In reply to this post by Carl Mastrangelo
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 [[hidden email]] On Behalf Of Carl Mastrangelo
Sent: Tuesday, September 19, 2017 3:57 AM
To: [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Realistic expectations of AtomicLongFieldUpdater

Carl Mastrangelo
In reply to this post by David Holmes-6
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 <[hidden email]> 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:[hidden email]]
Sent: Wednesday, September 20, 2017 6:33 AM
To: [hidden email]
Cc: [hidden email]
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 <[hidden email]> 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:[hidden email]] On Behalf Of Carl Mastrangelo
Sent: Tuesday, September 19, 2017 3:57 AM
To: [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Realistic expectations of AtomicLongFieldUpdater

Carl Mastrangelo
In reply to this post by Alex Otenko
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 <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 [[hidden email]] On Behalf Of Carl Mastrangelo
Sent: Tuesday, September 19, 2017 3:57 AM
To: [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest





_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Realistic expectations of AtomicLongFieldUpdater

David Holmes-6
In reply to this post by Alex Otenko

If you use more than one updater to update the same field, or you mix updater use with raw access, then there is no guarantee of atomicity.

 

For initialization, as long as you don’t publish “this” before construction is complete, there can be no atomicity issues because there is no concurrency.

 

David

 

From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Carl Mastrangelo
Sent: Thursday, September 21, 2017 11:31 AM
To: [hidden email]
Cc: [hidden email]
Subject: Re: [concurrency-interest] Realistic expectations of AtomicLongFieldUpdater

 

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 <[hidden email]> 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:[hidden email]]
Sent: Wednesday, September 20, 2017 6:33 AM
To: [hidden email]
Cc: [hidden email]
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 <[hidden email]> 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:[hidden email]] On Behalf Of Carl Mastrangelo
Sent: Tuesday, September 19, 2017 3:57 AM
To: [hidden email]
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Realistic expectations of AtomicLongFieldUpdater

Doug Lea
In reply to this post by Carl Mastrangelo
On 09/20/2017 09:31 PM, Carl Mastrangelo wrote:

> 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?
>

The disclaimer was initially introduced (late in Java 1.5 development)
because of a few seldom-used, now-obsolete processors (Power5, some Via
chips) without a CAS-like operation as wide as the corresponding
bitwise-atomic write.  It is obviously a crummy state of affairs,
in that practically no one ever needed to pay attention to the
disclaimer (but was there just in case), and it does not apply to
any current platforms. It does not appear in VarHandle specs (that
normally replace FieldUpdaters anyway). Since the disclaimer will never
be needed again  (no processor designed after the year 2000 or so would
do this), it should be removed. (It also has no impact on j.u.c
internals, since they all use VarHandles instead of FieldUpdaters).

-Doug


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest