[
https://issues.apache.org/jira/browse/CASSANDRA-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010687#comment-13010687
]
Sylvain Lebresne commented on CASSANDRA-1954:
---------------------------------------------
bq. Ideas?
Can't we just have some volatile boolean that we check before writing (and wait
on some simpleCondition if the boolean is set). We could set that flag (and the
condition) whenever we detect that we're over capacity, and release the flag
and condition when a flush thread gets available.
> Double-check or replace RRW memtable lock
> -----------------------------------------
>
> Key: CASSANDRA-1954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1954
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Stu Hood
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 0.8
>
> Attachments:
> 0001-Double-check-in-maybeSwitchMemtable-to-minimize-writeL.txt,
> 0001-Remove-flusherLock-readLock.patch, 1954-0.7-v2.txt, 1954-v2.txt,
> 1954_trunk.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> {quote}...when a Memtable reaches its threshold, up to (all) N write threads
> will often notice, and race to acquire the writeLock in order to freeze the
> memtable. This means that we do way more writeLock acquisitions than we need
> to...{quote}
> See CASSANDRA-1930 for backstory, but adding double checking inside a read
> lock before trying to re-entrantly acquire the writelock would eliminate most
> of these excess writelock acquisitions.
> Alternatively, we should explore removing locking from these structures
> entirely, and replacing the writeLock acquisition with a per-memtable counter
> of active threads.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
