Hi, Thanks for all the replies.
I still think the easiest way round the issue is to initialise all the static fields up-front, i.e. inline in their declarations or in a static initializer block, thus losing lazy initialization but avoiding synchronization issues. I think that for the relatively small number of fields involved, losing the lazy aspect wouldn't be such a big deal - this approach is already used in several other classes, e.g. DateTimeFieldType. Regards, Al. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Caleb Richardson Sent: 06 August 2007 08:07 To: [email protected] Subject: Re: [Joda-interest] Thread safety of PeriodType static methods On second thought, I don't think that declaring the fields of PeriodType volatile would make this code thread safe prior to Java 1.5. The variable assignments in PeriodType's constructor could be reordered with the cMonths variable assignment, and other threads could see uninitialized values. Caleb Richardson --- Brian S O'Neill wrote: 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 > > --- Brian S O'Neill wrote: > > 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 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 [email protected] https://lists.sourceforge.net/lists/listinfo/joda-interest This is an email from the CPP Group Plc, Holgate Park, York, YO26 4GA; telephone +44 (0)1904 544500. This message may contain information that is confidential. If you are not the intended recipient, you may not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify the sender immediately by email, facsimile or telephone and either return or destroy the original message. The CPP Group Plc accepts no responsibility for any changes made to this message after it has been sent by the original author. This email has been scanned for all viruses by the MessageLabs Email Security System. ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/joda-interest
