.
This is what I mean by atomic. From
An operation acting on shared memory is atomic if it completes in a single step relative to other threads. When an atomic store is performed on a shared variable, no other thread can observe the modification half-complete. When an atomic load is performed on a shared variable, it reads the entire value as it appeared at a single moment in time. Non-atomic loads and stores do not make those guarantees.
No disagreement here. It is just that
m_reqId++ is not one step but (at least) four: load, copy, increment, and store. In Java possibly unboxing, boxing, and various value conversions as well. So by that definition the operation m_reqId++ cannot be atomic.
The term "atomic" is being used in these posts to refer to thread synchronization when that is not what it means. Atomicity does not address what value a thread will see when multiple threads are accessing the same integer.
The term "atomic" in these posts was very much used in line with the definition you gave and was focused on the operation
m_reqId++ independent of threads executing the operation.
And we established that the operation
m_reqId++ consists of at least four steps and is therefore not atomic. As a consequence of the non-atomicity, two or more threads can lend up with the same orderId (in the case of m_orderId++) unless thread synchronization is added.
JR (out)
