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)