[
https://issues.apache.org/jira/browse/IGNITE-2333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15162703#comment-15162703
]
Ilya Lantukh commented on IGNITE-2333:
--------------------------------------
{quote}
For now this lock will be used mostly by system pool. And system pool threads
start immediately on node start. As such, Thread.getId() will give worse index
distribution than AtomicInteger.incrementAndGet(). Please rework it to atomics.
{quote}
As I understand, you suggest to use
{noformat}
int idx = counter.getAndIncrement() % locks.length;
{noformat}
on readLock() call. Please correct me if I am wrong.
Unfortunately, GridDhtPartitionTopologyImpl strongly relies on the fact that
readLock() will always return the same instance for the same thread. It's
public interface has readLock() and readUnlock() methods that don't return Lock
reference. There are quite a number of places where these methods are used.
Should I rework it as part of this ticket?
Other problems have been fixed.
> Hotspot in GridDhtPartitionTopologyImpl readLock() and readUnlock() methods
> ---------------------------------------------------------------------------
>
> Key: IGNITE-2333
> URL: https://issues.apache.org/jira/browse/IGNITE-2333
> Project: Ignite
> Issue Type: Sub-task
> Components: cache, general
> Affects Versions: ignite-1.4
> Reporter: Vladimir Ozerov
> Assignee: Ilya Lantukh
> Fix For: 1.6
>
>
> When running simple PUT benchmark in ATOMIC cache, read lock-unlock consumes
> up to 10% of time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
