[ 
https://issues.apache.org/jira/browse/HDFS-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747347#action_12747347
 ] 

Steve Loughran commented on HDFS-566:
-------------------------------------

I should add that a 64-bit server VM will use atomic 64 bit read/write 
operations; the risk of a partial write being visible is one for 32 bit 
machines. 

The language spec section 17.4 says

"The load, store, read, and write actions on volatile variables are atomic, 
even if the type of the variable is double or long."



> 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: Improvement
>          Components: name-node
>    Affects Versions: 0.21.0
>            Reporter: Steve Loughran
>            Priority: Minor
>
> 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.

Reply via email to