[concurrency-interest] question about spec for AtomicIntegerFieldUpdater

Josh Humphries jh at squareup.com
Mon Dec 8 10:33:43 EST 2014

> However, all hotspot-targeted processors have at least 32bit
> atomic set and CAS, so j.u.c and other internal JDK code
> have always been lax about this for ints. But there is still
> at least one supported processor (Power32) that needs this treatment
> for 64bit longs, so you still see explicit use internally
> (for example AbstractQueuedLongSynchronizer.setState.)

Ok. That sounds about like what I was expecting. So I'm safe using a
standard field write for 32-bit values as long as I'm okay with the
potential loss of portability to non-Oracle JVMs.

For Power32, how do volatile semantics work for long and double values
without word-tearing?

Also, I'm looking at the source for AbstractQueuedLongSynchronizer.setState
(in Java SE 1.8.0_20):

     * Sets the value of synchronization state.
     * This operation has memory semantics of a {@code volatile} write.
     * @param newState the new state value
    protected final void setState(long newState) {
        state = newState;

It's just using a simple volatile write. Am I missing something?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20141208/633e06e1/attachment.html>

More information about the Concurrency-interest mailing list