Lets put getAndUpdate() aside for now, because is not what the question about. Of course we can add this operation to Java, no problems. But we are talking about a single CAS, not spin-loop.
The problem is that for .Net/CPP guy CAS on long is not "bool CAS(old, new)". For him CAS is "long CAS(old, new)", where returned value is either "new" in case of success, or what was in place of "old" in case of failure. And we definitely will implement platform datastructures in that way, because we cannot force .Net/CPP users use Java concepts instead of their native counterparts. For platforms this can be achieved with only minor change to GridCacheAtomicLongImpl.internalCompareAndSet. So we can even do not place it on Java public API, because as for Java users this is really "weird". On Thu, Sep 17, 2015 at 9:18 PM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > 2015-09-17 10:55 GMT-07:00 Vladimir Ozerov <voze...@gridgain.com>: > > This is not something weird, but rather how things work everywhere except > > of Java. getAndUpdate() is not what we need, because it is a CAS loop, > not > > CAS. > > > > This is an implementation detail. For a distributed data structure it will > never be a CAS loop because we always acquire a lock for the corresponding > cache entry and then run an entry processor. Agree with Sergi, I would > rather name it getAndUpdate to be consistent with java AtomicLong since > this is the class which IgniteAtomicLong was mimicking in the first place. >
