33

AtomicInteger works with two concepts : CAS and volatile variable.

Using volatile variable insures that the current value will be visible to all threads and it will not be cached.

But I am confused over CAS(compare AND set) concept which is explained below:

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

My question is that whatif(compareAndSet(current, next) returns false? Will the value not be updated? In this case what will happen when a Thread is executing the below case:

private AtomicInteger count = new AtomicInteger();
count.incrementAndGet();
Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Onki
  • 1,879
  • 6
  • 38
  • 58
  • 1
    http://blog.slaks.net/2013-07-22/thread-safe-data-structures/ – SLaks Sep 17 '15 at 15:39
  • More complete explanation: https://www.baeldung.com/java-atomic-variables – nir Jul 14 '19 at 02:10
  • The loop is there till the next value is have been successfully updated, but since java 8+ you can simply call getAndAdd(1), N.B just need to pass in the delta which is 1 here. No need to loop anymore, all taken care for you by JDK. https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/atomic/AtomicInteger.html#getAndAdd-int- – RoundPi Jun 14 '20 at 20:13

2 Answers2

37

The atomic objects make use of Compare and Swap mechanism to make them atomic - i.e. it is possible to guarantee that the value was as specified and is now at the new value.

The code you posted continually tries to set the current value to one more than it was before. Remember that another thread could also have performed a get and is trying to set it too. If two threads race each other to change the value it is possible for one of the increments to fail.

Consider the following scenario:

  1. Thread 1 calls get and gets the value 1.
  2. Thread 1 calculates next to be 2.
  3. Thread 2 calls get and gets the value 1.
  4. Thread 2 calculates next to be 2.
  5. Both threads try to write the value.

Now because of atomics - only one thread will succeed, the other will recieve false from the compareAndSet and go around again.

If this mechanism was not used it would be quite possible for both threads to increment the value resulting in only one increment actually being done.

The confusing infinite loop for(;;) will only really loop if many threads are writing to the variable at the same time. Under very heavy load it may loop around several times but it should complete quite quickly.

OldCurmudgeon
  • 64,482
  • 16
  • 119
  • 213
10

for (;;) is an infinite loop, so it will just retry the attempt.

Dragan Bozanovic
  • 23,102
  • 5
  • 43
  • 110