Declaring the fields of PeriodType volatile should make this thread safe in all 
JVMs, however in Java 1.5 and later a better solution is to simply declare all 
fields of PeriodType final.

See http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html

Simply declaring the static field cMonths as volatile would work in Java 1.5 
and later as well.

Both solutions that use volatile are gross misuses of the keyword, and will 
perform similarly to the synchronized keyword.

If Joda must stay compatible with 1.4 and prior, and the synchronized keyword 
must be avoided, then the Holder Class idiom can be used instead.

Caleb Richardson

--- [EMAIL PROTECTED] wrote:

From: "Brian O'Neill" <[EMAIL PROTECTED]>
To: "Discussion of the Joda project" <joda-interest@lists.sourceforge.net>
Subject: Re: [Joda-interest] Thread safety of PeriodType static methods
Date: Fri, 3 Aug 2007 10:58:14 -0700

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



-------------------------------------------------------------------------
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

Reply via email to