[
https://issues.apache.org/jira/browse/HADOOP-12593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032331#comment-15032331
]
Sangjin Lee commented on HADOOP-12593:
--------------------------------------
I don't think that's a real issue. The key assumption here is that there is
only a single writer thread (these are basically thread-local data structures).
With volatile declarations and a single writer thread, even if a reader comes
in during the "+=" operation it's not going to be a problem.
I'd be the first to admit that the way it is written is not very clear or
intentional, but t appears correct. The only exception to the single-writer
rule is Statistics.rootData. However, that is also currently protected by the
Statistics instance lock. Again, that could be made more explicit (e.g.
sometimes synchronization is done in a couple of layers above in the call
chain).
Hope this helps.
> 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)
