> 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 is structured this way to avoid the race between
checking the volatile reference and accessing it. Whether
txCapsule is synchronised is very relevant because the assumption
in the code is that txCapsule is thread safe. It is the
responsibility of txCapsule to make sure that all data accessed
within is correct.
> However, it works. It's not based on any assumptions about
> the compiler
> or the JVM.
It does, I do not disagree.
> 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.
I totally agree and that is not what I am proposing. I am proposing
that the problem, the race for a volatile reference, be removed by
making it non volatile.
The access to the volatile reference is being made directly into
main memory. By moving this into a local reference you are removing
the volatility of the value, or should be hence .....
>
> > 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... :-)
...
I asked the question because I am not aware of any. The compiler
should not be allowed to optimise the access to the local copy
because it changes the semantics of the code. You implied in your
previous email that this may be happening, I am asking for you (or
someone else) to tell me what optimisation is being performed.
Kev
Kevin Conner
Orchard Information Systems Limited
Newcastle Technopole, Kings Manor
Newcastle Upon Tyne, NE1 6PA. United Kingdom
Registered in England, Number 1900078
Tel: +44 (0) 191-2032536 Fax: +44 (0) 191 2302515
-------------------------------------------------------
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
