[
https://issues.apache.org/jira/browse/HBASE-6755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452731#comment-13452731
]
Lars Hofhansl commented on HBASE-6755:
--------------------------------------
That "random stuff" looks dodgy, but I was going to leave that for another day.
Hmm. You make a good point about the variable needing to be volatile. Does it?
If it was not, threads running on different cores would not "see" the increment
immediately, hence increment to the same value and then invoke the "random
stuff", because the next number was used already. Random itself is using
AtomicLong, so avoiding it is also important.
The question is how likely is this going to happen and it is worth the volatile
or AtomicInt to guard against it. Since this is on the path of every write to
HBase it is worth thinking about.
The change might be simple, but the discussion is not. :)
> HRegion.internalObtainRowLock uses unecessary AtomicInteger
> -----------------------------------------------------------
>
> Key: HBASE-6755
> URL: https://issues.apache.org/jira/browse/HBASE-6755
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.96.0, 0.94.2
>
> Attachments: 6755-0.96.txt
>
>
> I was looking at HBase's implementation of locks and saw that is
> unnecessarily uses an AtomicInteger to obtain a unique lockid.
> The observation is that we only need a unique one and don't care if we happen
> to skip one.
> In a very unscientific test I saw the %system CPU reduced when the
> AtomicInteger is avoided.
--
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
