cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-1954) Double-check or replace RRW memtable lock
Date Thu, 24 Mar 2011 16:06:06 GMT


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

View raw message