[
https://issues.apache.org/jira/browse/HBASE-10117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13844040#comment-13844040
]
Lars Hofhansl commented on HBASE-10117:
---------------------------------------
Was thinking that in next() (0.94) we remove the scanner from the set of
current scanners; when next() is done we'd put it back. That way all
synchronization is handled by the "scanners" map, and we can still ensure that
no two client threads can ever use the same scanner at the same time.
Would be a bit tricky to reason about leases then (a lease could expire before
we put the scanner back into the scanners map).
That all said, if a scanner is used with scanner caching > 1 and this simple
change is committed I do not expect any great improvements from removing
synchronization from the remaining methods.
> Avoid synchronization in HRegionScannerImpl.isFilterDone
> --------------------------------------------------------
>
> Key: HBASE-10117
> URL: https://issues.apache.org/jira/browse/HBASE-10117
> Project: HBase
> Issue Type: Bug
> Components: Performance
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.94.15, 0.96.2, 0.98.1, 0.99.0
>
> Attachments: 10117-0.94-v2.txt, 10117-0.94-v3.txt, 10117-0.94.txt,
> 10117-trunk-v2.txt, 10117-trunk.txt
>
>
> A while ago I introduced HRegoinScannerImpl.nextRaw() to allow coprocessors
> and scanners with caching > 1 to avoid repeated synchronization during
> scanning (which puts up memory fences, which in turn slows things down on
> multi core machines).
> Looking at the code again I see that isFilterDone() is called from nextRaw()
> and isFilterDone() is synchronized.
> The caller of nextRaw is required to ensure single threaded access to
> nextRaw() anyway, we can call an unsynchronized internal version of
> isFilterDone().
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
