using for(boolean haveNext = false;;) instead of while(cond)

user_13886040 0
Viewed 114

Here is a code snippet from AtomicInteger:

public final int accumulateAndGet(int x,
                                  IntBinaryOperator accumulatorFunction) {
    int prev = get(), next = 0;
    for (boolean haveNext = false;;) {
        if (!haveNext)
            next = accumulatorFunction.applyAsInt(prev, x);
        if (weakCompareAndSetVolatile(prev, next))
            return next;
        haveNext = (prev == (prev = get()));
    }
}

Is there any specific reason of using for(... instead of while(... or it's just a programming choice?

Is it because of the reordering done by the jvm?

java-8 concurrency multithreading java
3 Answers

This is because the loop is left in the middle, not at the start (then programmer could use "while"), or end (then programmer could use "do ... while"). It is not connected with reordering.

user_12063010

TLDR.: This is done to prevent an unnecessary remapping of next.

This is because of the "weak" nature of the weakCompareAndSetVolatile:

/**
 * Possibly atomically sets the value to {@code newValue}
 * if the current value {@code == expectedValue},
 * with memory effects as specified by
 * {@link VarHandle#weakCompareAndSet}.
 *
 * @param expectedValue the expected value
 * @param newValue the new value
 * @return {@code true} if successful
 * @since 9
 */
public final boolean weakCompareAndSetVolatile(V expectedValue, V newValue) {
    return VALUE.weakCompareAndSet(this, expectedValue, newValue);
}

On the "weak" nature of the weakCompareAndSet's:

"... But on other platforms such as PowerPC or ARM (without LSE extension) CAS is implemented as a sequence of several instructions which provide LL/SC behavior and memory barriers as separate building blocks. This creates some wiggle room how strong your CAS can be both in terms of ordering and failure guarantees."

What the Javadoc defines as "May fail spuriously."

Because of the possibility of these false negatives, the line haveNext = (prev == (prev = get())); needs to reassure that the CAS failed because of a true miss (a change in the volatile value), and not because it "failed spuriously".

In reality, this would not be needed if the function accumulatorFunction.applyAsInt(prev, x); would not be required to redefine next each time prev received a volatile write, hence changing its value... on each loop, meaning the reason for this double check is to prevent an unnecessary remapping of next.

At first glance it seems as if a mismatched version of next could happen in between loops (when a wrong version of prev passes the function), and that is correct. BUT the mismatched version will never be set because by the time the loop reaches the weakCompareAndSetVolatile, the expected value will not match, and so the entire process will retry, until everything matches.

user_112146430

In that specific use case for AtomicInteger the variable can be defined within the scope of usage once where as with a while-loop it would be defined out-side of the scope of the iteration. I would assume that played into the choice of iteration mechanism.

user_44179240
Related