Sergi, we already have getAndSet, is getAndUpdate any different? On Fri, Sep 18, 2015 at 3:53 PM, Sergi Vladykin <sergi.vlady...@gmail.com> 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 <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. > > > > > > > > > > > > > > > -- -- Pavel Tupitsyn GridGain Systems, Inc. www.gridgain.com
