The problem with all these 'tricks' to avoid synchronization is that they
rely on all sorts of assumptions about both the compiler and the underlying
memory model. Unfortunately the JVM spec is such that you really can't make
these assumptions.
See
The problem with all these 'tricks' to avoid synchronization
is that they
rely on all sorts of assumptions about both the compiler and
the underlying
memory model. Unfortunately the JVM spec is such that you
really can't make
these assumptions.
See
But this isn't related to the problem. This code is trying to protect
against a stale volatile reference occuring between the initial comparison
and the access, it is not saying that the object being referenced is
thread safe. It is still the responsibility of the txCapsule object
to
The code is structured this way (catching NPE's) to avoid
synchronization as
stated in the comment in the code. If all the methods in
TransactionImpl were
synchronized there would be no problem, apart from the
performance. Whether
txCapsule is synchronized is irrelevant.
No, the code
On Thu, Jul 18, 2002 at 12:24:50PM +0100, Kevin Conner wrote:
The code is structured this way (catching NPE's) to avoid
synchronization as
stated in the comment in the code. If all the methods in
TransactionImpl were
synchronized there would be no problem, apart from the
OK, the fact that TxCapsule is thread-safe *is* important in
the overall
scheme of things, but for the purpose of this argument, 'Is
there a better
way than catching the NPE's it's not'
It is relevant only because you cited the double checked
locking. My point was that this problem had
Yep, but you cannot guarantee the source of the NPE. It is
feasible that the NPE could be generated by a problem in the
called methods and this code will hide that.
Ah ha! good point, and a reason to change IMHO.
It is not a trick, it is the correct use of volatile. The compilers
