[
https://issues.apache.org/jira/browse/HDFS-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tsz Wo (Nicholas), SZE updated HDFS-566:
----------------------------------------
Priority: Minor (was: Blocker)
I agree that both read and write of fields should be synchronized in general.
However, in the current NameNode implementation, all accesses (read/write) to
INode have to first obtain the global lock, rootDir, Therefore, there is no
synchronization problem.
For this issue, we could possibly remove "synchronized" from
INode.updatePermissionStatus(..) to avoid confusion.
> INode.permissions should be marked as volatile to avoid synchronization
> problems
> --------------------------------------------------------------------------------
>
> Key: HDFS-566
> URL: https://issues.apache.org/jira/browse/HDFS-566
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: name-node
> Affects Versions: 0.21.0
> Reporter: Steve Loughran
> Priority: Minor
> Fix For: 0.21.0
>
>
> Looking at INode, I can see that the long permissions field is updated in the
> synchronized updatePermissions, read in other non-synchronized contexts
> I believe that to avoid race conditions and other synchronisation problems,
> the field should be marked {{volatile}}
> # The Java language specification declares that {{long}} and {{double}} can
> be written as two 32-bit writes, unless the field is {{volatile}}
> http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html#28733
> # The JVM is free to re-order accesses to non-volatile data; reads of the
> permission may pick up out of date values
> # Volatile data may be cached/optimised out, changes may not propagate
> I don't think its enough to make the write operation synchronised, as the
> reads are still unsynchronized, and in other threads can pick up values
> midway through the update, or cache the value.
> It's a simple fix: declare permissions as {{volatile}}.
> {code}
> private volatile long permissions;
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
