Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <1799474765.1261138578094.JavaMail.jira@brutus>
Date: Fri, 18 Dec 2009 12:16:18 +0000 (UTC)
From: "Hudson (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Commented: (HARMONY-6405) [classlib][luni] String.equals()
 is not thread-safe
In-Reply-To: <514273425.1260538278119.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HARMONY-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12792450#action_12792450 ] 

Hudson commented on HARMONY-6405:
---------------------------------

Integrated in Harmony-1.5-head-linux-x86_64 #585 (See [http://hudson.zones.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/585/])
    Fix for  ([classlib][luni] String.equals() is not thread-safe)


> [classlib][luni] String.equals() is not thread-safe
> ---------------------------------------------------
>
>                 Key: HARMONY-6405
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6405
>             Project: Harmony
>          Issue Type: Bug
>    Affects Versions: 5.0M12
>            Reporter: Sebb
>            Assignee: Tim Ellison
>             Fix For: 5.0M13
>
>
> AFAICT, String.equals() is not thread-safe.
> It includes the following code (wrapped for ease of reference):
> if (count != s.count     // 1
> || (hashCode != s.hashCode     // 2 
>   && hashCode != 0     // 3
>   && s.hashCode != 0)) {     //4
> return false;     //5
> Suppose both Strings refer to the same sequence of characters, so equals() should return true.
> Suppose the hashCode has not yet been calculated for "s", but it has been calculated for "this".
> At the start:  hashCode != s.hashCode and count == s.count
> Line 1 all threads see equality , because count is final.
> Line 2 thread A sees hashCode != s.hashCode, i.e. potentially different Strings
> Thread B then does s.hashCode() and sets s.hashCode !=0
> Line 3 thread A sees hashCode !=0, which is correct
> Line 4 thread A sees s.hashCode !=0, which is different from before
> Line 5 thread A returns false, whereas thread B will return true.
> One possible solution is to fetch the hashCodes into local variables; the values cannot then change unexpectedly.
> Although thread A won't see the updated hashCode for "s", that does not matter, because only non-zero codes matter for this comparison.
> It should also work if the hashCodes were compared after checking for non-zero, but it would be less fragile (and likely quicker) to fetch each value once.

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