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.
