[
https://issues.apache.org/jira/browse/CASSANDRA-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975638#action_12975638
]
Jonathan Ellis commented on CASSANDRA-1370:
-------------------------------------------
nit: would prefer calling "newmap" oldMap, priorMap, otherMap, or previousMap.
otherwise, +1
> 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.
