RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family (original) (raw)

Aleksey Shipilev aleksey.shipilev at oracle.com
Thu Jan 10 23:03:44 UTC 2013

On 01/09/2013 05:54 PM, Doug Lea wrote:

On 01/09/13 08:04, Aleksey Shipilev wrote:

c) While existing, Java-level AtomicLong.VMSUPPORTLONGCAS is redundant, and can be eliminated. AtomicLongFieldUpdater can be rewritten to use Unsafe on all the paths.

There is one little nicety here that does rely on VMSUPPORTLONGCAS. There is a disclaimer somewhere that CAS is guaranteed to atomic only wrt other CASes. But in the emulation code for updaters, we also lock unconditional writes, because not doing so would be surprising.

Ok, I spent some time thinking about this, so I can ask the stupid question now. What's surprising? I can't understand how that blows up if we do put/getLongVolatile() in ALFU.LockedUpdater, and do get()/set() without the locking.

A good case can be made that the fallback wrapper for putLongVolatile should itself use a lock in this case but for reasons I don't remember, this wasn't done. (and in any case wouldn't trap syntactically generated volatile writes.) So there may be some usage code that is officially wrong/surprising on these grounds.

Ummm. Examples? I'm OK with exploring the darkest side of Unsafe :)

-Aleksey.

More information about the core-libs-dev mailing list