On Wed, 06 Jun 2012 23:29:52 +0200, Kalle Korhonen <kalle.o.korho...@gmail.com>
wrote:
On Wed, Jun 6, 2012 at 1:51 PM, Cezary Biernacki <cezary...@gmail.com> wrote:
On 06 June 2012 21:20:02 +0200 Howard Lewis Ship <hls...@gmail.com> wrote:
http://tapestryjava.blogspot.com/2012/06/synchronized-considered-harmful.html
I am curious is there a reason to not use 'double-checked locking' pattern?
I know that it was broken in Java 1.4 and earlier, but Java Memory Model was
changed (JSR-133) for Java 5.0 to accommodate that pattern. Of course, you
need to use 'volatile' field, but AFAIK it does not impose any significant
penalty (especially for reads) on most platforms including most x86 and
emt64. Am I missing something?
Same question, and I think there's still more places in T5 code that
could simply return the object if it exists before synchronizing or
obtaining locks if the field was volatile. Specifically, even before
the try block, could you not do:
if (messages != null) return messages;
Or, depending on where it's cleaned up:
Messages messages = this.messages;
if (messages != null) return messages;
If I'm not mistaken, JSR-133 only affects final fields so we still have the
same problem for non-final fields.
i.e any non-final fields in Messages might still be uninitialized even if the
*reference* is visible to other threads (messages != null)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
