Vladimir, Signature "long CAS(old, new)" does not work in my understanding. Imagine current value is 0 and 2 threads do CAS(0, 1). Both will get 1? How can I distinguish which thread really succeeds? Or one of the threads will get "0"?
As far as .net API, I am OK to have .net approach for such functionality. --Yakov 2015-09-17 21:42 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > 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. > > >
