However, atomic variables will not ensure, by themselves the atomicity of an operation that modifies multiples atomic variables, because other threads could be modifying those same varibles concurrently.
This last point is a conclusion of mine while developing this code, and I just wanted to make sure that it is correct. That is why I wrote this thread here at Java Ranch.
What do you, guys, think of this particular case?
Interesting approach that you propose, Henry. Frankly, I did not know I could do that.
In this particular example that you wrote, if I am getting it correctly, the calculations will repeat when any concurrent modification of any of the variables happens.
That means that if the concurrency is unlikely to happen this approach may increase performance since it does not use synchronization. However, if the concurrency happens too often then it would be necessary to evaluate what is more expensive: waiting for the contended lock or recalculating the variables again.
Do you have any idea about how to control fairness with this approach, Henry?
I mean, if I were using synchronization with a ReentrantLock I could stablish lock fairness in true as an attempt to make sure that all waiting threads will ever get executed.