[ https://issues.apache.org/jira/browse/HBASE-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ramkrishna.s.vasudevan reassigned HBASE-7160: --------------------------------------------- Assignee: Hiroshi Ikeda > Improve IdLock and remove its minor defects > ------------------------------------------- > > Key: HBASE-7160 > URL: https://issues.apache.org/jira/browse/HBASE-7160 > Project: HBase > Issue Type: Improvement > Reporter: Hiroshi Ikeda > Assignee: Hiroshi Ikeda > Priority: Minor > Attachments: HBASE-7160.patch > > > Combination of synchronizations and concurrent collections complicates the > code, and it is hard to trace the code and to confirm its correctness. We > should re-create the class and make it more understandable. > In the current code, I find the following minor defects: > (1) In the case that there is a waiting thread for a lock in getLockEntry() > and another thread is releasing the lock by calling releaseLockEntry(), > trying to get the lock with a 3rd thread by calling getLockEntry() falls into > a busy loop until the waiting thread wakes up and gets the lock. > Even if notify() wakes up the blocked thread and causes a context switch to > the waked thread immediately, synchronization might block the waked thread > and cause another context switch, and the busy loop might continue for a > while. > (2) In the same case as (1), since releasing the lock is merely notifying > without removing the lock-entry from the map, interrupting the waiting thread > might leave an unused lock-entry (entry.numWaiters == 0) in the map. This is > a memory leak unless the id of the lock is used again. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira