[
https://issues.apache.org/jira/browse/CASSANDRA-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874191#comment-13874191
]
Benedict commented on CASSANDRA-5549:
-------------------------------------
bq. When does CLQ block? Are you thinking of LBQ?
It's double locked, so lock to read, lock to write. Also double-lock to
Iterator remove. So by NonBlockingQueue, I mean WaitFreeQueue, not
NoBlockingMethodQueue :-)
bq. So if we can call NBQ an optimization
If it weren't for WaitQueue I'd say it were just an optimisation, but it's
likely to cause real wasted cycles. I've seen it happening, it's not a
theoretical risk, the only question is how big the problem would be given the
use case of WaitQueue.... and the answer is, I'm not sure. There's a reasonable
chance it will only trigger wasted cycles infrequently, in which case we can
address it later.
CASSANDRA-6557 really needs it to fix the bug I spotted, though, so we'll have
to put it in before release anyway. Not sure that buys you much respite!
> 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)
