cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5549) Remove Table.switchLock
Date Thu, 16 Jan 2014 23:41:25 GMT


Benedict commented on CASSANDRA-5549:

bq. We have ANBQ -> NBQV -> NBQ, with no other implementations.

NBQV and NBQ should be kept separate, as having two different queues modifying state could
get ugly. They could strictly speaking probably be merged at the moment, but unpicking them
in future might be difficult, and I'm not sure it's helpful. ABQ I use for OffHeap memtables,
as I have a more memory efficient queue for storing references necessary for GC (at least
until we move more off-heap).

bq. What is the difference between NBQ and CLQ? I'd be inclined to introduce NBQ in a separate

FIrstly, NBQ is non-blocking, CLQ is not. This is a nice property to have in and of itself,
as we now have an almost totally non-blocking read and write path (actually codahale is now
one of the only main blocking points, other than the obvious memtable/CL flushes), which maybe
not immediately useful may allow us some neat optimisations in the near future.

Secondly, NBQ provides some very useful methods, most specifically appendIfTail() and removeHeadIf().
Even though CLQ *could* offer these methods, it doesn't, and it makes certain things very
difficult to write. These are mostly useful for the off-heap memtables, but I also use them
for CASSANDRA-6557 to fix a potentially dangerous bug, and make the code easier to understand.

Lastly, and the only reason to include it in _this_ ticket, is the snap() functionality that
allows a persistent view of the queue that (mostly) does not change. In WaitQueue, since it
is now used extensively in more highly concurrent places with spurious wake ups, this is really
essential: waiting threads can (actually very easily) wake-up, find they have no work to do,
and go back to sleep again _before the signalling thread has reached the end of the queue_,
meaning they get woken up again... potentially repeatedly. This is especially a risk due to
the use of pthread mutexes to implement LockSupport.park/unpark - whilst the signalling thread
releases the waiting thread's mutex before waking it, if that thread is state changing at
that time anyway, the signalling thread will wait (a full scheduler delay), and this can happen

> Remove Table.switchLock
> -----------------------
>                 Key: CASSANDRA-5549
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>            Assignee: Benedict
>              Labels: performance
>             Fix For: 2.1
>         Attachments: 5549-removed-switchlock.png, 5549-sunnyvale.png
> As discussed in CASSANDRA-5422, Table.switchLock is a bottleneck on the write path. 
ReentrantReadWriteLock is not lightweight, even if there is no contention per se between readers
and writers of the lock (in Cassandra, memtable updates and switches).

This message was sent by Atlassian JIRA

View raw message