[
https://issues.apache.org/jira/browse/CASSANDRA-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874158#comment-13874158
]
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 ticket.
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 repeatedly.
> Remove Table.switchLock
> -----------------------
>
> Key: CASSANDRA-5549
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5549
> 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
(v6.1.5#6160)
