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
Joda-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/joda-interest

Reply via email to