ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Adding compare-and-set method returning value to distributed atomics
Date Thu, 17 Sep 2015 18:42:51 GMT
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.

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