[
https://issues.apache.org/jira/browse/CASSANDRA-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975650#action_12975650
]
Hudson commented on CASSANDRA-1370:
-----------------------------------
Integrated in Cassandra-0.6 #39 (See
[https://hudson.apache.org/hudson/job/Cassandra-0.6/39/])
Avoid synchronization in getPendingRanges.
Patch by brandonwilliams, reviewed by jbellis for
CASSANDRA-1370
> TokenMetaData.getPendingRangesMM() is unnecessarily synchronized
> ----------------------------------------------------------------
>
> Key: CASSANDRA-1370
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1370
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 0.6
> Reporter: Jason Fager
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.6.9, 0.7.1
>
> Attachments: 1370.txt
>
>
> TokenMetaData.getPendingRangesMM() is currently synchronized to avoid a race
> condition where multiple threads might create a multimap for the given table.
> However, the pendingRanges instance variable that's the subject of the race
> condition is already a ConcurrentHashMap, and the race condition can be
> avoided by using putIfAbsent, leaving the case where the table's map is
> already initialized lock-free:
> private Multimap<Range, InetAddress> getPendingRangesMM(String table)
> {
> Multimap<Range, InetAddress> map = pendingRanges.get(table);
> if (map == null)
> {
> map = HashMultimap.create();
> Multimap<Range, InetAddress> fasterHorse
> = pendingRanges.putIfAbsent(table, map);
> if(fasterHorse != null) {
> //another thread beat us to creating the map, oh well.
> map = fasterHorse;
> }
> }
> return map;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
