Pavel, just compare signatures, they serve different purposes. https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/AtomicLong.html#getAndUpdate-java.util.function.LongUnaryOperator- https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/AtomicLong.html#getAndSet-long-
Sergi 2015-09-18 16:00 GMT+03:00 Pavel Tupitsyn <[email protected]>: > Sergi, we already have getAndSet, is getAndUpdate any different? > > On Fri, Sep 18, 2015 at 3:53 PM, Sergi Vladykin <[email protected]> > wrote: > > > 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 <[email protected]>: > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > -- > -- > Pavel Tupitsyn > GridGain Systems, Inc. > www.gridgain.com >
