The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
"I'm not back." - Bill Harding, Twister
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.
Another question:
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.
Consider Paul's rocket mass heater. |