harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] Closed: (HARMONY-6405) [classlib][luni] String.equals() is not thread-safe
Date Sat, 09 Jan 2010 20:03:54 GMT

     [ https://issues.apache.org/jira/browse/HARMONY-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sebb closed HARMONY-6405.
-------------------------


Looks good to me

> [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.


Mime
View raw message