I was not aware that the new JMM had special rules for final fields. Since PeriodType has only final fields, if another thread gains access to PeriodType while it is under construction, it cannot see the field values until they are assigned. So, PeriodType is already thread safe as of Java 1.5.
Caleb Richardson wrote: > 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
