ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: Adding compare-and-set method returning value to distributed atomics
Date Fri, 18 Sep 2015 09:30:30 GMT
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.
> >
>

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