[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-lambda-dev
Subject:    let's play TDD, tackles closures in java
From:       reinier () zwitserloot ! com (Reinier Zwitserloot)
Date:       2010-12-21 9:24:03
Message-ID: AANLkTik+Eq-PrHj-z5N=f9azTws7dWpdysWeqhEJ1+8V () mail ! gmail ! com
[Download RAW message or body]

I do not agree with your assessment that its equally like to mix up
incrementAndGet(inc) vs. set(get() + inc), and foo += 20; and foo = 20. In
fact, += is currently defined as no different from foo = foo + 20, but if we
apply this to AtomicInteger, then all of a sudden there _is_ a difference -
a very important one, even.

I also do not agree that there's precedent with IINC vs. IADD. When you mix
up set(get() + 20) and incrementAndGet, you'll get thread sync bugs. These
are notoriously hard to debug and notoriously easy to miss. Mixing up IINC
vs. IADD doesn't lead to problems even remotely close to this.

Given that the current lambda sentiment is all about: "Let's be careful
handing folks dangerous weapons at this point in time - multicore is easy to
get wrong and there's not much experience around right now" - a sentiment I
happen to agree with, I rather doubt giving someone the tools to effectively
blow their leg off this easily and invisibly (foo = foo + 20; is a bug in
most scenarios, if foo is an AtomicInteger), well, it'll never fly. I don't
see any further point in discussing it, though we should revisit this issue
for coinflip, maybe there are ways to fix this*.

 --Reinier Zwitserloot


On Tue, Dec 21, 2010 at 10:07 AM, Artur Biesiadowski <abies at adres.pl> wrote:

> On 21/12/2010 08:41, Reinier Zwitserloot wrote:
> 
> > 
> > 
> > AtomicInteger foo = 10;
> > foo = foo + 20;
> > 
> > would be desugared into either:
> > 
> > AtomicInteger foo = new AtomicInteger(10);
> > foo.set(foo.get() + 20);
> > 
> > 
> But you can write same thing with atomic integers right now ? Same way as
> you need to know difference between foo.set(foo.get() +20) versus
> foo.incrementAndGet(20), you would need to know difference between foo > foo+20 \
> versus foo +  (and bytecodes iload, iadd, istore versus iinc) 
> If you are concerned about what 'normal people' would do, normal people
> will write right now
> 
> int[] holder = new int[1];
> ...
> holder[0] += 20;
> 
> and be completely sure it is atomic and threadsafe...
> 
> But I agree that java is probably not ready for operator overloading yet.
> Same way as we constantly need to educate people that
> String str = "...";
> str += a;
> str += b;
> str += c;
> is something very different from
> str += a + b + c;
> 
> there would be no end to suprises about 'non-intuitive' behaviour of
> Atomic* overloads.
> 
> Regards,
> Artur Biesiadowski
> 


[prev in list] [next in list] [prev in thread] [next in thread]