[
https://issues.apache.org/jira/browse/HDFS-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14081736#comment-14081736
]
Andrew Wang commented on HDFS-6788:
-----------------------------------
I don't see any cases where a thread with the read lock would try to get the
write lock. The four methods that take the read lock are getNamespaceInfo,
getActiveNN, getBlockPoolId, and toString, and they all look safe.
+1 pending Jenkins from me.
Yongjun, for the indirection, it's probably not a big deal since the JIT is
pretty likely to inline it. Unless we see this crop up as an issue, I'm
inclined not to bother since we have much bigger perf issues (for instance,
that there is a global RW lock).
> Improve synchronization in BPOfferService with read write lock
> --------------------------------------------------------------
>
> Key: HDFS-6788
> URL: https://issues.apache.org/jira/browse/HDFS-6788
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: datanode
> Affects Versions: 2.5.0
> Reporter: Yongjun Zhang
> Assignee: Yongjun Zhang
> Attachments: HDFS-6788.001.patch, HDFS-6788.002.patch
>
>
> Threads in DN (DataXceiver, PacketResponder, Async disk worker etc) may block
> at BPOfferService.getBlockPoolId() when calling BPOfferService.checkBlock(),
> though they are just reading the same blockpool id. This is unnecessary
> overhead and may cause performance hit when many threads compete. Filing this
> jira to replace synchronized method with read write lock
> (ReentrantReadWriteLock).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
