AtomicReferenceArray writes and visibility

[Volker Borchert]

Hello all,

reading on the "new" memory model and AtomicReferenceArray, it
seems that anything done before a .set() on an AtomicReferenceArray
"happens-before" anything done after a .get() on the same
AtomicReferenceArray.

Two questions:

1. Am I right?
2. If so, does this hold true if the write does not actually change
the value, in other words, if the write only "refreshes" the
memory location?

Thank you

V.B.

 

[Kevin McMurtrie]

Hello all,

reading on the "new" memory model and AtomicReferenceArray, it
seems that anything done before a .set() on an AtomicReferenceArray
"happens-before" anything done after a .get() on the same
AtomicReferenceArray.

Two questions:

1. Am I right?
2. If so, does this hold true if the write does not actually change
the value, in other words, if the write only "refreshes" the
memory location?

Thank you

V.B.

For the weakCompareAndSet methods, it's not a matter of values being set
then destroyed by collisions. The difference is that when you're
operating on multiple values, threads may see those values change in a
different order than they are set. A multithreaded operation which
requires a sequence of changes to multiple values may fail. The weak
methods may also return false more often than expected.

At least in my source code, the weakCompareAndSet versions have no
special operation. It looks like Sun may expect that some systems can
run faster when memory syncing rules are relaxed. On a multi-core Intel
x86 CPU, multiple threads can't write to the same CPU block of memory at
once. The only performance difference between the 'atomic' package and
a 'synchronized' block is that a synchronized block caries a high risk
of a thread losing it's CPU time (quanta runs out) while the lock is
held. The 'atomic' operations have no such risk.

 

[markspace]

Hello all,

reading on the "new" memory model and AtomicReferenceArray, it
seems that anything done before a .set() on an AtomicReferenceArray
"happens-before" anything done after a .get() on the same
AtomicReferenceArray.

Two questions:

1. Am I right?

No. I know how the assembly language compare-and-swap instructions work,
and there's little chance that they would be implemented with a memory
barrier. It could happen, on certain systems, but in general there's no
synchronization, and no happens-before.


Read the source code for the AtomicReferenceArray. set() doesn't use
any synchronization. It calls sun.misc.Unsafe#putObjectVolatile(). I
don't see how that's going to create a happens-before.

 

[markspace]

[...]
Read the source code for the AtomicReferenceArray. set() doesn't use any
synchronization. It calls sun.misc.Unsafe#putObjectVolatile(). I don't
see how that's going to create a happens-before.

"volatile" creates the happens-before. All writes before a volatile
write in the same thread must be visible in a given thread after a
volatile read in the same thread from the same location.

I didn't notice the keyword volatile there. Did I miss it?

Regardless, the lack of any guarantees in the docs of
AtomicReferenceArray would kill it for me. You can't be sure how the
implementation will change over time.

 

[markspace]

The relevant use of "volatile" is in the java.util.concurrent.atomic
package documentation,
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/package-summary.html

Yup, I'd missed that. Looks like Volker was right. Thanks for the
correction, I learned something today.

 

[Lew]

You misattributed that second quote.

http://tfwiki.net/wiki/Power_Play!

And likely earlier.

Sorry, you can't claim credit.

 

[Volker Borchert]

Essentially, but not literally. You need to qualify your statement to
specify that the action that occurs before the write (the call to set())
has to be in the same thread as the write, and the action that occurs
after the read (the call to get()) has to be in the same thread as the read.

That was implied, I forgot to state it explicitly. Thanks for the
clarification.