Actually, this lazy assignment is not thread-safe. The pointer assignment
is, but the JVM is allowed to "optimize" the constructor invocation by
assigning cMonths before calling the constructor. Another thread might get a
PeriodType which has null fields (iNames, iTypes, iInstances).
Without reverting to synchronization, the only way to make this thread-safe
(as of JDK1.5) is to declare the fields as volatile.
On 8/3/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
>
> Alastair Rodgers wrote:
> > The various static methods which return the singleton PeriodType
> > instances (e.g. months(), years(), etc.) all use lazy initialization to
> > set the underlying static field values on first use. However, they just
> > use a simple guard against null to check for first use, e.g.
> >
> > public static PeriodType months() {
> > PeriodType type = cMonths;
> > if (type == null) {
> > type = new PeriodType( ... );
> > cMonths = type;
> > }
> > return type;
> > }
> >
> > Two threads could simultaneously call the method, both could see (type
> > == null) and attempt to initialise the static field. Assigning a field
> > value to an object reference is not guaranteed to be atomic, so I think
> > there's a small chance of it causing problems.
>
> Firstly, as I understand it, assigning an object reference to a variable
> is atomic.
>
> More significantly however is that it doesn't matter if two PeriodType
> objects get created - the second one will simply overwrite the first in
> the static variable of PeriodType. The effect will be that the first one
> created will typically just be a short--lived object as seen by the
> caller of the method that created it. As such, it is important to
> compare two PeriodType objects using .equals(), not using ==.
>
> > Wouldn't it be safer to just initialise all the static fields in a
> > static initializer block, which is guaranteed to be called just once?
> > You'd lose the lazy initialization, but that's perhaps not such a big
> > deal.
> One of the issues with the current java datetime libraries is excessive
> synchronization. We did our best to avoid it wherever possible.
>
> Stephen
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Joda-interest mailing list
> Joda-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Joda-interest mailing list
Joda-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/joda-interest
