ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya Lantukh (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-2333) Hotspot in GridDhtPartitionTopologyImpl readLock() and readUnlock() methods
Date Wed, 24 Feb 2016 09:13:18 GMT

    [ 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:

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.

As I understand, you suggest to use
int idx = counter.getAndIncrement() % locks.length;
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

View raw message