[ https://issues.apache.org/jira/browse/HDFS-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Chansler updated HDFS-566: --------------------------------- Priority: Blocker (was: Minor) Fix Version/s: 0.21.0 Issue Type: Bug (was: Improvement) > 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: Blocker > 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.