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

[Aleksey Shipilev]

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.VM_SUPPORT_LONG_CAS 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 
> VM_SUPPORT_LONG_CAS. 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.