Actually I can recall discussions related to this signature on java concurrency interest mailing list, there were some proponents of adding such a method into Atomics, but the final resolution was that it is not that much different from existing compareAndSet to do the needed number of squats (it needs intrinsics for different JVM platforms, also there were some argues about performance, correctness and stuff like that).
I agree that we should go as close to platforms as possible, but for Java API it is the same, we should stay as close as possible to how things are done in Java. BTW, it seems that getAndUpdate() can be really efficient for us (avoiding round trip on get() and then on compareAndSet() which can fail), may be we should create a respective Jira issue and ask someone to implement it? It must be easy IMO even for newbies. Thoughts? Sergi 2015-09-18 12:35 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > 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 <yzhda...@apache.org> > 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 <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. > > > > > > > > > >
