[jira] [Commented] (HADOOP-10487) Racy code in UserGroupInformation#ensureInitialized()

["Daryn Sharp (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HADOOP-10487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13965396#comment-13965396 ] 

Daryn Sharp commented on HADOOP-10487:
--------------------------------------

I missed Todd's comment.  I might be wrong, but I believe the DCL in this case is ok.  The normal problem is when simple assignment to the DCL object occurs in the sync block.  The full construction of the object may be reordered to be outside the sync block.  In this case, full construction is guaranteed because the {{initialize}} method repeatedly accesses the {{Configuration}} object prior to assignment.  The synch block's happens-before semantics I believe negate the need for a final.

> Racy code in UserGroupInformation#ensureInitialized()
> -----------------------------------------------------
>
>                 Key: HADOOP-10487
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10487
>             Project: Hadoop Common
>          Issue Type: Bug
>            Reporter: Haohui Mai
>            Assignee: Haohui Mai
>
> UserGroupInformation#ensureInitialized() uses the double-check-locking pattern to reduce the synchronization cost:
> {code}
>   private static void ensureInitialized() {
>     if (conf == null) {
>       synchronized(UserGroupInformation.class) {
>         if (conf == null) { // someone might have beat us
>           initialize(new Configuration(), false);
>         }
>       }
>     }
>   }
> {code}
> As [~tlipcon] pointed out in the original jira (HADOOP-9748). This pattern is incorrect. Please see more details in http://en.wikipedia.org/wiki/Double-checked_locking and http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> This jira proposes to use the static class holder pattern to do it correctly.



--
This message was sent by Atlassian JIRA
(v6.2#6252)