[
https://issues.apache.org/jira/browse/HADOOP-12593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030725#comment-15030725
]
Gabor Liptak commented on HADOOP-12593:
---------------------------------------
In
https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/fs/FileSystem.java:
{code:Java}
* There is only a single writer to thread-local StatisticsData objects.
* Hence, volatile is adequate here-- we do not need AtomicLong or similar
* to prevent lost updates.
* The Java specification guarantees that updates to volatile longs will
* be perceived as atomic with respect to other threads, which is all we
* need.
volatile long bytesRead;
volatile long bytesWritten;
this.bytesRead += other.bytesRead;
this.bytesWritten += other.bytesWritten;
{code}
Could this above cause a race condition?
PS ZK also worked these with
https://issues.apache.org/jira/browse/ZOOKEEPER-1972
> multiple "volatile long" field declarations exist in the Hadoop codebase
> ------------------------------------------------------------------------
>
> Key: HADOOP-12593
> URL: https://issues.apache.org/jira/browse/HADOOP-12593
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 2.8.0
> Reporter: Steve Loughran
> Priority: Minor
>
> If you get your IDE to scan for "volatile long", you find 20-30 entries.
> Volatile operations on `long` variables are not guaranteed to be atomic, so
> these usages can be vulnerable to race conditions generating invalid data.
> they need to be replaced by AtomicLong references, except in the specific
> case that you want performance values for statistics, and are prepared to
> take the risk
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
