[
https://issues.apache.org/jira/browse/HBASE-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458584#comment-13458584
]
Hiroshi Ikeda commented on HBASE-6651:
--------------------------------------
On #2, RoundRobinPool simply gives the next pooled resource for the next
caller, and after taking a round it gives the pooled resource again, but the
resource might be yet used. RoundRobinPool has the following code:
{code}
class RoundRobinPool<R> extends CopyOnWriteArrayList<R> implements Pool<R> {
...
@Override
public R get() {
if (size() < maxSize) {
return null;
}
nextResource %= size();
R resource = get(nextResource++);
return resource;
}
{code}
On #3, in general concurrent collections have the advantage of peformance in
multi-threads because they are not blocked and don't cause context switches,
which have large overhead. But in other word you cannot use concurrent
collections to block other threads in order to make critical sections where
only one thread may run. There are some tips to create unblocking codes with
using concurrent utilities, but in general it is difficult for complex logics.
On #1, I'm not sure what to say, but ThreadLocal might bind tasks to specific
threads, which is hard to use and is appropriate only for some restricted cases.
> Thread safety of HTablePool is doubtful
> ---------------------------------------
>
> Key: HBASE-6651
> URL: https://issues.apache.org/jira/browse/HBASE-6651
> Project: HBase
> Issue Type: Bug
> Components: client
> Affects Versions: 0.94.1
> Reporter: Hiroshi Ikeda
> Priority: Minor
> Attachments: sample.zip
>
>
> There are some operations in HTablePool to access to PoolMap in multiple
> times without any explict synchronization.
> For example HTablePool.closeTablePool() calles PoolMap.values(), and calles
> PoolMap.remove(). If other threads add new instances to the pool in the
> middle of the calls, the new added instances might be dropped.
> (HTablePool.closeTablePool() also has another problem that calling it by
> multple threads causes accessing HTable by multiple threads.)
> Moreover, PoolMap is not thread safe for the same reason.
> For example PoolMap.put() calles ConcurrentMap.get() and calles
> ConcurrentMap.put(). If other threads add a new instance to the concurent map
> in the middle of the calls, the new instance might be dropped.
> And also implementations of Pool have the same problems.
--
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
