You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Hiroshi Ikeda (JIRA)" <ji...@apache.org> on 2014/04/21 04:51:15 UTC
[jira] [Created] (HADOOP-10524) Race condition around MutableMetric
and its subclasses
Hiroshi Ikeda created HADOOP-10524:
--------------------------------------
Summary: Race condition around MutableMetric and its subclasses
Key: HADOOP-10524
URL: https://issues.apache.org/jira/browse/HADOOP-10524
Project: Hadoop Common
Issue Type: Bug
Reporter: Hiroshi Ikeda
Priority: Minor
For example, MutableGaugeInt has two methods:
{code}
public synchronized void incr() {
++value;
setChanged();
}
public void set(int value) {
this.value = value;
setChanged();
}
{code}
and the lack of synchronization of the {{set}} method causes a problem that calling the {{set}} method might be ignored while another thread is calling the {{incr}} method, such as:
(1) Thread1 takes the current value in the {{incr}} method.
(2) Thread2 sets the new value in the {{set}} method.
(3) Thread1 adds +1 to the taken value and sets the value in the {{incr}} method.
Also, in the first place, MutableMetric has a volatile instance variable {{changed}}, but lack of synchronization causes a problem that it drops the latest notification which is called just before clearing the {{changed}} variable. That means, the volatile keyword is useless unless it is needed to just check the flag itself. Indeed, the implementation of the method {{snapshot}} in MutableCounterInt has this problem because of lack of synchronization.
Anyway, synchronization around MutableMetric and its subclasses is doubtful and should be reviewed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)