ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@gridgain.com>
Subject Re: Adding compare-and-set method returning value to distributed atomics
Date Fri, 18 Sep 2015 13:00:57 GMT
Sergi, we already have getAndSet, is getAndUpdate any different?

On Fri, Sep 18, 2015 at 3:53 PM, Sergi Vladykin <sergi.vladykin@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 <vozerov@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 <yzhdanov@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 <vozerov@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.goncharuk@gmail.com> wrote:
> > > >
> > > > > 2015-09-17 10:55 GMT-07:00 Vladimir Ozerov <vozerov@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message