AtomicInteger.incrementAndGet() vs. AtomicInteger.getAndIncrement()

Question

When return value is not of interest, is there any (even irrelevant in practice) difference between AtomicInteger.getAndIncrement() and AtomicInteger.incrementAndGet() methods, when return value is ignored?

I'm thinking of differences like which would be more idiomatic, as well as which would put less load in CPU caches getting synchronized, or anything else really, anything to help decide which one to use more rationally than tossing a coin.

Solution 1

Since no answer to the actual question has been given, here's my personal opinion based on the other answers (thanks, upvoted) and Java convention:

incrementAndGet()

is better, because method names should start with the verb describing the action, and intended action here is to increment only.

Starting with verb is the common Java convention, also described by official docs:

"Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized."

Solution 2

The code is essentially the same so it does not matter:

public final int getAndIncrement() {
    for (;;) {
        int current = get();
        int next = current + 1;
        if (compareAndSet(current, next))
            return current;
    }
}

public final int incrementAndGet() {
    for (;;) {
        int current = get();
        int next = current + 1;
        if (compareAndSet(current, next))
            return next;
    }
}

Solution 3

No, there's no difference (if you don't care about the return value).

The code of those methods (in the OpenJDK) differs only in that one uses return next and the other uses return current.

Both use compareAndSet under the hood with the exact same algorithm. Both need to know both the old and the new value.

Solution 4

Just want to add to existing answers: there could be very small non-noticeable difference.

If you look at this implementation:

public final int getAndIncrement() {
    return unsafe.getAndAddInt(this, valueOffset, 1);
}

public final int incrementAndGet() {
    return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}

Note - both function call exactly the same function getAndAddInt, except +1 part, which means that in this implementation getAndIncrement is faster.

But, here is older implementation:

public final int getAndIncrement() {
    for (;;) {
        int current = get();
        int next = current + 1;
        if (compareAndSet(current, next))
            return current;
    }
}

public final int incrementAndGet() {
    for (;;) {
        int current = get();
        int next = current + 1;
        if (compareAndSet(current, next))
            return next;
    }
}

The only difference is return variable, so both functions perform exactly the same.

View more solutions

Comments

[irreputable]

incrementAndGet()==getAndIncrement()+1

[assylias]

@irreputable Not sure I get your point - if you don't store the returned value, var.incrementAndGet(); and var.getAndIncrement(); produce exactly the same result...

[irreputable]

yes. I'm saying actually one of the methods is enough, the other is kind of redundant.

[assylias]

@irreputable Ah sorry... Yes. Also I'm not sure why incrementAndGet does not simply call addAndGet(1) instead of mostly duplicating the code...

[irreputable]

Doug Lea is obsessed with every CPU cycle:)

[assylias]

@irreputable Following-up on that in this question.

[hyde]

Thanks for your answer. However, in your answer, the result is actually used (printed). The question is about a situation where "When return value is not of interest"...

[Bennett Lynch]

Would be nice if they exposed a simple increment() method, just for the sake of readability.

[Delark]

I guess the reason why they kept it like that in atomicInteger() is to "maintain the convention" as the behaviour of returning either "prev" or "next" becomes a necessity when dealing with atomic swaps. This is not useful in integers since the next will always be prev + 1 (and prev == next -1), but when dealing with objects it is extremely useful. More problematic to me is the fact that a failed compareAndSet does not give you a witness.