> 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 protect itself using synchronization.
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. However, it works. It's not based on any assumptions about the compiler or the JVM. Replacing ugly fully functional code with a 'neat trick' based on the assumption that the compiler won't optimize it is IMHO a waste of everyones effort. > Are there any compiler optimisations which would invalidate this code? > The assumption is that the volatile reference will be copied into a local Exactly my point... :-) -- regards Neale Swinnerton ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
