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