harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wendy Feng (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-6651) Broken double checked locking in DragSourceContext.java
Date Sun, 19 Sep 2010 02:12:34 GMT
Broken double checked locking in DragSourceContext.java 

                 Key: HARMONY-6651
                 URL: https://issues.apache.org/jira/browse/HARMONY-6651
             Project: Harmony
          Issue Type: Bug
          Components: Classlib
    Affects Versions: 6.0M1
         Environment: Windows Xp
            Reporter: Wendy Feng

I found broken double-checked locking in modules/nio_char/src/main/java/java/nio/charset/Charset.java

public abstract class Charset implements Comparable<Charset>{
public static SortedMap<String, Charset> availableCharsets() {
        // Initialize the built-in charsets map cache if necessary
        if (null == _builtInCharsets) {
            synchronized (Charset.class) {
                if (null == _builtInCharsets) {
                    _builtInCharsets = new TreeMap<String, Charset>(

The double checked locking idiom is broken in the code above. In current Java memory model
(JMM), the writes initializing the TreeMap object and the write to the _builtInCharesets field
could be reordered by the compiler, processor or memory system. It means the write to _builtInCharesets
can happen before the writes in TreeMap object initialization. 

When multiple threads access the code simultaneously, threads can see a non-null _builtInCharesets
field, but the TreeMap can be partially constructed (e.g. The elementData array is not created
yet). Then these threads invoke clone() method on the partially initialized TreeMap, which
will result in undesired behavior, e.g. Throwing NullPointerException. The error doesn't manifest
all the time due to the non-deterministic nature of multi-threading, but it would be too bad
to leave the code depend on the undefined behavior.

In JDK 5 or above, declaring the _builtInCharesets field as volatile can fix the problem.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message