Adding compare-and-set method returning value to distributed atomics

[Vladimir Ozerov]

Igniters,

As we know Java implementation of atomics are rather limited because it
cannot return current value in case of failed CAS. Other modern platforms
like .Net, WinAPI and GCC have this feature.

We can easily implement this method because we have old value in hands
during distributed CAS. But how to name it?

- long compareAndSetValue(long, long)?
- compareAndSetReturnValue(long, long)?

Please share your ideas.

For examples, GCC goes this way:
__sync_*bool*_compare_and_set
__sync_*val*_compare_and_set

Vladimir.

[Pavel Tupitsyn-3]

Hi,

Looking at other methods in IgniteAtomicLong, it would be
compareAndSetAndGet. Ugly, but consistent.

On Thu, Sep 17, 2015 at 3:36 PM, Vladimir Ozerov <[hidden email]>
wrote:

> Igniters,
>
> As we know Java implementation of atomics are rather limited because it
> cannot return current value in case of failed CAS. Other modern platforms
> like .Net, WinAPI and GCC have this feature.
>
> We can easily implement this method because we have old value in hands
> during distributed CAS. But how to name it?
>
> - long compareAndSetValue(long, long)?
> - compareAndSetReturnValue(long, long)?
>
> Please share your ideas.
>
> For examples, GCC goes this way:
> __sync_*bool*_compare_and_set
> __sync_*val*_compare_and_set
>
> Vladimir.
>

--
--
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com

[dsetrakyan]

On Thu, Sep 17, 2015 at 4:19 PM, Pavel Tupitsyn <[hidden email]>
wrote:

> Hi,
>
> Looking at other methods in IgniteAtomicLong, it would be
> compareAndSetAndGet. Ugly, but consistent.
>

Agree.

>
> On Thu, Sep 17, 2015 at 3:36 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Igniters,
> >
> > As we know Java implementation of atomics are rather limited because it
> > cannot return current value in case of failed CAS. Other modern platforms
> > like .Net, WinAPI and GCC have this feature.
> >
> > We can easily implement this method because we have old value in hands
> > during distributed CAS. But how to name it?
> >
> > - long compareAndSetValue(long, long)?
> > - compareAndSetReturnValue(long, long)?
> >
> > Please share your ideas.
> >
> > For examples, GCC goes this way:
> > __sync_*bool*_compare_and_set
> > __sync_*val*_compare_and_set
> >
> > Vladimir.
> >
>
>
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
>

[Sergi]

Instead of inventing something weird looking I'd better take a closer look
at
what happens in Java 8 and 9.

For example in Java 8 there is already a method AtomicLong.getAndUpdate[1]
(paired
with updateAndGet of course) which provides the needed semantics.
We can implement it reusing known current value if CAS failed.

[1]
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/AtomicLong.html#getAndUpdate-java.util.function.LongUnaryOperator-

Sergi


2015-09-17 17:20 GMT+03:00 Dmitriy Setrakyan <[hidden email]>:

> On Thu, Sep 17, 2015 at 4:19 PM, Pavel Tupitsyn <[hidden email]>
> wrote:
>
> > Hi,
> >
> > Looking at other methods in IgniteAtomicLong, it would be
> > compareAndSetAndGet. Ugly, but consistent.
> >
>
> Agree.
>
>
> >
> > On Thu, Sep 17, 2015 at 3:36 PM, Vladimir Ozerov <[hidden email]>
> > wrote:
> >
> > > Igniters,
> > >
> > > As we know Java implementation of atomics are rather limited because it
> > > cannot return current value in case of failed CAS. Other modern
> platforms
> > > like .Net, WinAPI and GCC have this feature.
> > >
> > > We can easily implement this method because we have old value in hands
> > > during distributed CAS. But how to name it?
> > >
> > > - long compareAndSetValue(long, long)?
> > > - compareAndSetReturnValue(long, long)?
> > >
> > > Please share your ideas.
> > >
> > > For examples, GCC goes this way:
> > > __sync_*bool*_compare_and_set
> > > __sync_*val*_compare_and_set
> > >
> > > Vladimir.
> > >
> >
> >
> >
> > --
> > --
> > Pavel Tupitsyn
> > GridGain Systems, Inc.
> > www.gridgain.com
> >
>

[Vladimir Ozerov]

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.
Since we are working on integration with other platforms where returning
value on failed CAS is what developer expect from API by default, we need
relevent API in Java.

On Thu, Sep 17, 2015 at 7:00 PM, Sergi Vladykin <[hidden email]>
wrote:

> Instead of inventing something weird looking I'd better take a closer look
> at
> what happens in Java 8 and 9.
>
> For example in Java 8 there is already a method AtomicLong.getAndUpdate[1]
> (paired
> with updateAndGet of course) which provides the needed semantics.
> We can implement it reusing known current value if CAS failed.
>
> [1]
>
> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/AtomicLong.html#getAndUpdate-java.util.function.LongUnaryOperator-
>
> Sergi
>
>
> 2015-09-17 17:20 GMT+03:00 Dmitriy Setrakyan <[hidden email]>:
>
> > On Thu, Sep 17, 2015 at 4:19 PM, Pavel Tupitsyn <[hidden email]>
> > wrote:
> >
> > > Hi,
> > >
> > > Looking at other methods in IgniteAtomicLong, it would be
> > > compareAndSetAndGet. Ugly, but consistent.
> > >
> >
> > Agree.
> >
> >
> > >
> > > On Thu, Sep 17, 2015 at 3:36 PM, Vladimir Ozerov <[hidden email]
> >
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > As we know Java implementation of atomics are rather limited because
> it
> > > > cannot return current value in case of failed CAS. Other modern
> > platforms
> > > > like .Net, WinAPI and GCC have this feature.
> > > >
> > > > We can easily implement this method because we have old value in
> hands
> > > > during distributed CAS. But how to name it?
> > > >
> > > > - long compareAndSetValue(long, long)?
> > > > - compareAndSetReturnValue(long, long)?
> > > >
> > > > Please share your ideas.
> > > >
> > > > For examples, GCC goes this way:
> > > > __sync_*bool*_compare_and_set
> > > > __sync_*val*_compare_and_set
> > > >
> > > > Vladimir.
> > > >
> > >
> > >
> > >
> > > --
> > > --
> > > Pavel Tupitsyn
> > > GridGain Systems, Inc.
> > > www.gridgain.com
> > >
> >
>

[Alexey Goncharuk]

2015-09-17 10:55 GMT-07:00 Vladimir Ozerov <[hidden email]>:

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.

[Vladimir Ozerov]

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 <
[hidden email]> wrote:

> 2015-09-17 10:55 GMT-07:00 Vladimir Ozerov <[hidden email]>:
>
> 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.
>

[Sergi]

If something like compareAndSetAndThenAgainGet will not pop up on public
Java API, I have no objections :)

Sergi

2015-09-17 21:42 GMT+03:00 Vladimir Ozerov <[hidden email]>:

> 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 <
> [hidden email]> wrote:
>
> > 2015-09-17 10:55 GMT-07:00 Vladimir Ozerov <[hidden email]>:
> >
> > 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.
> >
>

[yzhdanov]

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 <[hidden email]>:

> 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 <
> [hidden email]> wrote:
>
> > 2015-09-17 10:55 GMT-07:00 Vladimir Ozerov <[hidden email]>:
> >
> > 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.
> >
>

[Vladimir Ozerov]

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 <[hidden email]> 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 <[hidden email]>:
>
> > 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 <
> > [hidden email]> wrote:
> >
> > > 2015-09-17 10:55 GMT-07:00 Vladimir Ozerov <[hidden email]>:
> > >
> > > 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.
> > >
> >
>

[Sergi]

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 <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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 <
> > > [hidden email]> wrote:
> > >
> > > > 2015-09-17 10:55 GMT-07:00 Vladimir Ozerov <[hidden email]>:
> > > >
> > > > 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-3]

Sergi, we already have getAndSet, is getAndUpdate any different?

On Fri, Sep 18, 2015 at 3:53 PM, Sergi Vladykin <[hidden email]>
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 <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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 <[hidden email]>:
> > >
> > > > 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 <
> > > > [hidden email]> wrote:
> > > >
> > > > > 2015-09-17 10:55 GMT-07:00 Vladimir Ozerov <[hidden email]>:
> > > > >
> > > > > 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

[Sergi]

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 <[hidden email]>:

> Sergi, we already have getAndSet, is getAndUpdate any different?
>
> On Fri, Sep 18, 2015 at 3:53 PM, Sergi Vladykin <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>
> > > 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 <[hidden email]>:
> > > >
> > > > > 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 <
> > > > > [hidden email]> wrote:
> > > > >
> > > > > > 2015-09-17 10:55 GMT-07:00 Vladimir Ozerov <[hidden email]
> >:
> > > > > >
> > > > > > 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
>