Difference between i++ and i=i++

[Pablo Napoli]

Hi!. I know this is very basic but i'm very confused with this. I know that i++ change the value of i the next time thatit is used (unlike ++i). But i don't know why first it does not increase the value of the variable and then store it in "i".

This is one example:

for(int i=0 ;i<3; ){
   System.out.println(i);
   //i++;
   i = i++;
   System.out.println(i);
}

As we can see at runtime, the "i" variable stores the value of 0 and println() method prints 0. I really expected another behavior.

On the other hand, i want to show you guys this code snippet that behaves as i expect, because in the same statement the value of b chages:

int b = 2;
System.out.println(b++ + 2 * b); // 8

[Campbell Ritchie]

Pablo Napoli wrote:. . . i'm very confused with this.

Don't let it worry you. Everybody else gets confused, too.

I know that i++ change the value of i the next time thatit is used (unlike ++i). But i don't know why first it does not increase the value of the variable and then store it in "i". . . .

Afraid that is incorrect. The increased value is indeed stored in i immediately, but the whole expression i++ has the old value of i. Then the assignment (=) overwrites the new value of i with the old value.

int i = 0;
i = i++;
System.out.println(i);   // 0
System.out.println(i++); // 0
System.out.println(i);   // 1

[fred rosenberger]

So many people get confused on this, we have a FAQ devoted to it.

[Matt Wong]

well, the reason is the order of execution with post-increment
post-in/decrement: the old value is read and then updated
pre-in/decrement: the value is first updated and then read

this means: i=i++ says in words: read the current value of i (0), then update i (this is whats called an atomic process) (new value: +1), and now final store the read value of 0 back to i
so, i, wich is atomic increment gets overridden by the previous read value - and hence is always 0

you other example works like this:
read b (2) and increase it (3), the add with (first multiply 2 with the new value of b (3) = (6)) = 8
so, as java evaluates from left to right, b gets first read with the value of 2 and is immediately incremented to 3 as pre/post in/decrements are atomic - and the, as math rule first multiply/devide the add/sub gets in the new updated value b, wich is now 3, gets multiplied with 2, wich is 6 l, and is then added with the old value 2 read before post-increment to result 8

once you get your head around these rules (atomics, left-to-right eval, preserve math rules) it's easy to eval such line with pen and paper

[Pablo Napoli]

Thank you guys!. Having looked at those rules and the order of execution is easier than before following the flow of the program. Specially this part was very very clear:

this means: i=i++ says in words: read the current value of i (0), then update i (this is whats called an atomic process) (new value: +1), and now final store the read value of 0 back to i
so, i, wich is atomic increment gets overridden by the previous read value - and hence is always 0

Thanks!

[Campbell Ritchie]

Matt Wong wrote:well, the reason is the order of execution with post-increment . . .

Are you sure about that? Is that what it says in the Java® Language Specification (=JLS)? Look here. It doesn't say anything about order of execution, but says that the value of the whole expression is equal to the old value of the variable. I always look on it as meaning there are two values, the value of i and that of the whole expression i++.

. . . this is whats called an atomic process. . .

How do you know that x++ is atomic? I couldn't find anything in the JLS about ++ being atomic.

[Tim Holloway]

Campbell Ritchie wrote:How do you know that x++ is atomic? I couldn't find anything in the JLS about ++ being atomic.

I'm trying to find a way for it not to be atomic, and not succeeding.

At the Java level, "i++" is atomic in that it's a single operation and cannot be broken down into meaningful smaller components. You cannot inject any other operations into the function. You cannot even - unless I'm missing something - make postfix increment work on a sub-expression, only a single named variable. Or, I suppose on another pre/postfix operation.

At the bytecode level, I'm expecting (without checking) that there's an increment bytecode operator, so at that level, too, the operation would be atomic.

At the machine language level, things are murkier, since many machines also have an increment operator, but whether the increment operator can be the one and only machine instruction employed to realize the increment bytecode might vary depending on what sort of item you're post-incrementing. And on whether you're considering the target strictly as a register-only function or as a complete (updates memory) function. As an aside, on the IBM System/370 computers, pre-incrementing (and worse, pre-decrementing) is generally going to be more complicated at the instruction level than is post-incrementing, by there are many ways to implement these operations depending again on context.

Even given a single-instruction increment-memory-and-fetch machine instruction, it might be atomic at the machine code level but not at the microcode level, or in the case of a multiprocessor system at the bus level. Again, referencing the IBM instruction set, there were specific instructions guaranteed to be atomic at all levels, used for spin locks. It's been a long time since I looked at the Intel processor instruction set, but I seem to recall that they, too have such things. It's hard to run a multiprocessor system without something like that.

But, percolating back up to the Java source level, I'm pretty sure you're safe in considering pre- and post- increment/decrement subexpressions as "atomic", in the practical sense, if not in the formal sense for a single variable operand.

On the other hand, an expression such as "i++++" would not be atomic by those standards, so there's that. Now let's consider the saner version of that ("i += 2"). :) How atomic is that?

[Campbell Ritchie]

class AtomicDemo
{
    public void increment()
    {
        int i = 123;
        i++;
        System.out.println(i);
    }
}

....javap -c AtomicDemo Compiled from "AtomicDemo.java" class AtomicDemo {  AtomicDemo();    Code:       0: aload_0       1: invokespecial #1                  // Method java/lang/Object."<init>":()V       4: return  public void increment();    Code:       0: bipush        123       2: istore_1       3: iinc          1, 1       6: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;       9: iload_1      10: invokevirtual #3                  // Method java/io/PrintStream.println:(I)V      13: return } Well, the bytecode shows iinc 1, 1 as one stage, so you are probably right about ++ being executed as one operation. Whether that fulfils the formal definition of being immune from interference between competing accesses from multiple threads, I don't know. I presume the JLS would only call it atomic if it has that sort of immunity. I believe that = is atomic (not for longs and doubles), but I am not sure.
The JLS says that compound assignment is equivalent to casting, so, even if you optimise away the identity conversion, you have two stages the addition and the assignment. If I change the middle line to ++i; or i += 1;, neither seems to make any difference to the bytecode, and changing to i += 2; turns the line 3 to 3: iinc 1, 2. So it would appear the compiler can optimise the += away. That no longer works if I force the implicit cast by declaring i as a short in line 5.....javap -c AtomicDemo Compiled from "AtomicDemo.java" class AtomicDemo {  AtomicDemo();    Code:       0: aload_0       1: invokespecial #1                  // Method java/lang/Object."<init>":()V       4: return  public void increment();    Code:       0: bipush        123       2: istore_1       3: iload_1       4: iconst_2       5: iadd       6: i2s       7: istore_1       8: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;      11: iload_1      12: invokevirtual #3                  // Method java/io/PrintStream.println:(I)V      15: return }I presume the cast is instruction 6, but now the += seems to become a multi‑stage operation.

[Knute Snortum]

Does AtomicInteger fulfil the requirements?

https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/util/concurrent/atomic/AtomicInteger.html

[Campbell Ritchie]

Yes, AtomicInteger has all its methods atomic. According to the Sierra/Bates/Robson OCP8 study guide it uses a different chip instruction from the usual iadd. Can't remember any more details just at the moment.

[Mike Simmons]

Tim Holloway wrote:But, percolating back up to the Java source level, I'm pretty sure you're safe in considering pre- and post- increment/decrement subexpressions as "atomic", in the practical sense, if not in the formal sense for a single variable operand.

Not at the Java level either, once multithreading is considered.  The Java memory model described in the JLS makes no guarantees that would imply that an increment operation could be considered atomic.  And at a purely practical level, it's not difficult to observe in action:

import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;

public class NonatomicIncrements {
    private static volatile int primitiveInt;
    private static AtomicInteger atomicInt = new AtomicInteger();

    public static void main(String[] args) throws InterruptedException {
        final var numThreads = 10;
        final var numIncrementsPerThread = 10000;

        System.out.println( numThreads + " threads running " + numIncrementsPerThread + " increments each");
        System.out.println("initial values: primitiveInt=" + primitiveInt + ", atomicInt=" + atomicInt.get());

        runInNThreads(numThreads, () -> incrementNTimes(numIncrementsPerThread));

        System.out.println("final values: primitiveInt=" + primitiveInt + ", atomicInt=" + atomicInt.get());
    }

    private static void runInNThreads(int numThreads, Runnable task) throws InterruptedException {
        var pool = Executors.newFixedThreadPool(numThreads);
        for (int i = 0; i < numThreads; i++) {
            pool.submit(task);
        }
        pool.shutdown();
        pool.awaitTermination(1, TimeUnit.MINUTES);
    }

    private static void incrementNTimes(int numIncrementsPerThread) {
        for (int i = 0; i < numIncrementsPerThread; i++) {
            primitiveInt++;
            atomicInt.getAndIncrement();
        }
    }
}

Typical output for me:

10 threads running 10000 increments each
initial values: primitiveInt=0, atomicInt=0
final values: primitiveInt=77649, atomicInt=100000

If you don't see similar results, try increasing the numThreads or numIncrementsPerThread.  And note that I made primitiveInt volatile too, to see if that helped.  It didn't.

[Liutauras Vilda]

Pablo Napoli,

CowGratulations, your topic has been published in our CodeRanch Journal August Edition.

A copy of journal you could find here -> https://coderanch.com/wiki/715405/CodeRanch-Journal-August
Other than that, you, as everybody else supposed to get one emailed to you