I was a bit wrong when describing non-Java semantics. "long CAS(old, new)" returns what was "old" at the moment of CAS attempt. In your case it will be: T1: CAS(0, 1) => 0 (success) T2: CAS(0, 1) -> 1 (failure)
On Fri, Sep 18, 2015 at 12:30 PM, Yakov Zhdanov <[email protected]> wrote: > 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 <[email protected]>: > > > 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 < > > [email protected]> wrote: > > > > > 2015-09-17 10:55 GMT-07:00 Vladimir Ozerov <[email protected]>: > > > > > > 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. > > > > > >
