[
https://issues.apache.org/jira/browse/CASSANDRA-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010732#comment-13010732
]
Jonathan Ellis commented on CASSANDRA-1954:
-------------------------------------------
bq. 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
Now we are talking about:
volatile boolean
condition variable
writer atomic counter
Table.lock for switching
Is this really simpler/better than the old approach?
> 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
