The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Is that correct? Does that mean that thread1 can read the value of a variable and manipulate it and in the meantime thread2 cannot gain access to it? That sounds like a lock, not volatile. Or have I read the tutorial wrongly?That tutorial linked to wrote:. . . Access to the variable acts as though it is enclosed in a synchronized block, synchronized on itself. . . .
Campbell Ritchie wrote:
Is that correct? Does that mean that thread1 can read the value of a variable and manipulate it and in the meantime thread2 cannot gain access to it? That sounds like a lock, not volatile. Or have I read the tutorial wrongly?That tutorial linked to wrote:. . . Access to the variable acts as though it is enclosed in a synchronized block, synchronized on itself. . . .
Campbell Ritchie wrote:
Is that correct? Does that mean that thread1 can read the value of a variable and manipulate it and in the meantime thread2 cannot gain access to it? That sounds like a lock, not volatile. Or have I read the tutorial wrongly?That tutorial linked to wrote:. . . Access to the variable acts as though it is enclosed in a synchronized block, synchronized on itself. . . .
The synchronized implementation of getInstance(), while correctly preventing multiple
singleton objects from being created, has the problem that every single call to this
method will require synchronization. In practice, this can be costly and can impact
performance. Synchronization is only needed the first time that the object is created.
As you may have noticed, we added the volatile modifier to our singleton object. This
keyword prevents a subtle case where the compiler tries to optimize the code such that
that the object is accessed before it is finished being constructed.
This solution is better than our previous version, as it performs the synchronization
step only when the singleton does not exist. If our singleton is accessed thousands of
times over many hours or days, this means that only the first few calls would require
synchronization, and the rest would not.
This
keyword prevents a subtle case where the compiler tries to optimize the code such that
that the object is accessed before it is finished being constructed.
This solution is better than our previous version, as it performs the synchronization
step only when the singleton does not exist. If our singleton is accessed thousands of
times over many hours or days, this means that only the first few calls would require
synchronization, and the rest would not.
Ioanna Katsanou wrote:Since volatile does not ensure atomicity, how can it ensures that the object is accessed after it is finished being constructed??
Blueberry pie is best when it is firm and you can hold in your hand. Smell it. And smell this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|