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-lo
Sergi, we already have getAndSet, is getAndUpdate any different?
On Fri, Sep 18, 2015 at 3:53 PM, Sergi Vladykin
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, bu
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 n
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 wrote:
> Vladimir,
>
> Signature "lon
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 fu
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 :
> Lets put getAndUpdate() aside for now, because is not what the question
> about. Of course we can add this operation to Java, no problem
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,
2015-09-17 10:55 GMT-07:00 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.
>
This is an implementation detail. For a distributed data structure it will
never be a CAS lo
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 nee
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
On Thu, Sep 17, 2015 at 4:19 PM, Pavel Tupitsyn
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
> wrote:
>
> > Igniters,
> >
> > As we know Java implementation
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
wrote:
> Igniters,
>
> As we know Java implementation of atomics are rather limited because it
> cannot return current value in case of faile
12 matches
Mail list logo
