[
https://issues.apache.org/jira/browse/YARN-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14187058#comment-14187058
]
Karthik Kambatla commented on YARN-2761:
----------------------------------------
I am all up for fixing this, but the race itself shouldn't be a big deal. The
worst thing that can happen is - multiple threads would create multiple
instances of the policy and only one of them eventually goes to the map, the
rest would get GCed eventually. [~zhiguohong] - do you agree or am I missing
something?
> potential race condition in SchedulingPolicy
> --------------------------------------------
>
> Key: YARN-2761
> URL: https://issues.apache.org/jira/browse/YARN-2761
> Project: Hadoop YARN
> Issue Type: Bug
> Components: fairscheduler
> Reporter: Hong Zhiguo
> Assignee: Hong Zhiguo
> Priority: Minor
>
> reported by findbug.
> In SchedulingPolicy.getInstance, ConcurrentHashMap.get and
> ConcurrentHashMap.put is called. These two operations together should be
> atomic, but using ConcurrentHashMap doesn't guarantee this.
> {code}
> public static SchedulingPolicy getInstance(Class<? extends SchedulingPolicy>
> clazz) {
> SchedulingPolicy policy = instances.get(clazz);
> if (policy == null) {
> policy = ReflectionUtils.newInstance(clazz, null);
> instances.put(clazz, policy);
> }
> return policy;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
