Question

I’ve been reading about non-blocking approaches for some time. Here is a piece of code for so called lock-free counter.

public class CasCounter {
private SimulatedCAS value;

public int getValue() {
    return value.get();
}

public int increment() {
    int v;
    do {
        v = value.get();
    }
    while (v != value.compareAndSwap(v, v + 1));
    return v + 1;
}

}

I was just wondering about this loop:

do {
    v = value.get();
}
while (v != value.compareAndSwap(v, v + 1));

People say:

So it tries again, and again, until all other threads trying to change the value have done so. This is lock free as no lock is used, but not blocking free as it may have to try again (which is rare) more than once (very rare).

My question is:

How can they be so sure about that? As for me I can’t see any reason why this loop can’t be infinite, unless JVM has some special mechanisms to solve this.

Answer 1

The loop can be infinite (since it can generate starvation for your thread), but the likelihood for that happening is very small. In order for you to get starvation you need some other thread succeeding in changing the value that you want to update between your read and your store and for that to happen repeatedly.

It would be possible to write code to trigger starvation but for real programs it would be unlikely to happen.

The compare and swap is usually used when you don’t think you will have write conflicts very often. Say there is a 50% chance of “miss” when you update, then there is a 25% chance that you will miss in two loops and less than 0.1% chance that no update would succeed in 10 loops. For real world examples, a 50% miss rate is very high (basically not doing anything than updating), and as the miss rate is reduces, to say 1% then the risk of not succeeding in two tries is only 0.01% and in 3 tries 0.0001%.

The usage is similar to the following problem

Set a variable a to 0 and have two threads updating it with a = a+1 a million times each concurrently. At the end a could have any answer between 1000000 (every other update was lost due to overwrite) and 2000000 (no update was overwritten).

The closer to 2000000 you get the more likely the CAS usage is to work since that mean that quite often the CAS would see the expected value and be able to set with the new value.