[ https://issues.apache.org/jira/browse/HDFS-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Todd Lipcon updated HDFS-2533: ------------------------------ Attachment: hdfs-2533.txt Here's the simple patch. The reason this is correct is follows: - getBlockFile() doesn't itself access any in-memory structures. It calls validateBlockFile - validateBlockFile is unsynchronized. It also doesn't access any structures. It calls getFile() which _is_ synchronized (since it accesses in-memory state). Then it calls f.exists(). - it's safe to call f.exists() outside the lock because, even if we had the lock, someone could remove the file just after we exit this function. > Remove needless synchronization on FSDataSet.getBlockFile > --------------------------------------------------------- > > Key: HDFS-2533 > URL: https://issues.apache.org/jira/browse/HDFS-2533 > Project: Hadoop HDFS > Issue Type: Improvement > Components: data-node > Affects Versions: 0.23.0 > Reporter: Todd Lipcon > Assignee: Todd Lipcon > Priority: Minor > Attachments: hdfs-2533.txt > > > HDFS-1148 discusses lock contention issues in FSDataset. It provides a more > comprehensive fix, converting it all to RWLocks, etc. This JIRA is for one > very specific fix which gives a decent performance improvement for > TestParallelRead: getBlockFile() currently holds the lock which is completely > unnecessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira