Atomicity of increment operation

Question

I am learning multi-thread programming from 'Java Concurrency in Practice'.

At one point, book says that even an innocuous looking increment operation is not thread safe as it consists of three different operations...read,modify and write.

class A {
  private void int c;

  public void increment() {
    ++c;
  }
}

So increment statement is not atomic, hence not thread safe.

My question is that if an environment is really concurrent (ie multiple threads are able to execute their program statements exactly at same time) then a statement which is really atomic also can't be thread safe as multiple threads can read same value. So how can having an atomic statement help in achieving thread safety in a concurrent environment?

I want to say that atomic operations are supposed to help in achieving thread safety. But if multiple threads can execute atomic operations at exactly same point of time(even if possibility is very low) then even atomic operations can't be thread safe. For eg, assume increment operation is thread safe. So if 2 threads can execute it 'exactly' at same time then same value would be written finally in the incremented variable, which means we have lost one increment, meaning program incorrectness — Mandroid, Jul 25 '15 at 05:21
I guess any operation which claims to be atomic must not allow multiple threads to execute it simultaneously. — Mandroid, Jul 25 '15 at 05:26

score 2 · Accepted Answer · edited May 23 '17 at 12:14

True concurrency does not exist when it comes to modifying state.

This post has some good descriptions of Concurrency and Parallelism.

As stated by @RitchieHindle in that post:

Concurrency is when two tasks can start, run, and complete in overlapping time periods. It doesn't necessarily mean they'll ever both be running at the same instant. Eg. multitasking on a single-core machine.

As an example, the danger of non-atomic operations is that one thread might read the value, another might modify the value, and then the original thread might modify and write the value (thus negating the modification the second thread did).

Atomic operations do not allow other operations access to the state while in the middle of the atomic operation. If, for example, the increment operator were atomic, it would read, modify, and write without any other thread having access to that variables state while those operations took place.

Elliott Frisch · Answer 2 · 2015-07-25T05:20:17.267

You can use AtomicInteger. The linked Javadoc says (in part) that it is an int value that may be updated atomically. AtomicInteger also implements addAndGet(int) which atomically adds the given value to the current value

private AtomicInteger ai = new AtomicInteger(1); // <-- or another initial value
public int increment() {
    return ai.addAndGet(1); // <-- or another increment value
}

That can (for example) allow you to guarantee write order consistency for multiple threads. Consider, ai might represent (or include) some static (or global) resource. If a value is thread local then you don't need to consider atomicity.

Atomicity of increment operation

2 Answers2

Linked

Related