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 Fri, 17 Jan 2014 00:09:20 GMT


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