[
https://issues.apache.org/jira/browse/HBASE-6755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453887#comment-13453887
]
nkeywal commented on HBASE-6755:
--------------------------------
You can save an increment (Wow!), and may be some synchronisation issues with
this (not tested).
{noformat}
// loop until we generate an unused lock id
while (true) {
Integer lockId = ++lockIdGenerator;
HashedBytes existingRowKey = lockIds.putIfAbsent(lockId, rowKey);
if (existingRowKey == null) {
return lockId;
} else {
// lockId already in use, jump generator to a new spot
do {
lockIdGenerator = rand.nextInt();
}while (lockIds.putIfAbsent(lockIdGenerator , rowKey) == null);
return lockIdGenerator ;
}
}
} finally {
{noformat}
But if this piece of code is important for the performances, it may need some
rethinking imho, with stuff around native structures (int vs. Integer,
allocation per block, pre allocation (may be in a different thread)...
Is it that important?
> 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.3
>
> 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
