[jira] [Comment Edited] (CASSANDRA-5549) Remove Table.switchLock

["Benedict (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13871924#comment-13871924 ] 

Benedict edited comment on CASSANDRA-5549 at 1/15/14 11:01 AM:
---------------------------------------------------------------

For accepts() to work correctly the Ordered on which it is called MUST be exposed atomically wrt changing the "current" Ordered/Group. This is at the very least difficult with the scheme you suggest, and I think probably impossible. At least, not without synchronising on the OpOrdered, and doing everything that Barrier does, in the caller.

Note I have scrapped a lengthy message about how *expiring* atomically would also be ugly, as I hadn't yet realised that exposing atomically would be nearly impossible, which I hope underlines how difficult this is, and that encapsulating as much of it as possible in Barrier is a Good Thing. So that we only have to get it right the once.

Stylistically I also think it is *much* clearer to separate the two concepts.


was (Author: benedict):
For accepts() to work correctly the Ordered on which it is called MUST be exposed atomically wrt changing the "current" Ordered/Group. This is at the very least difficult with the scheme you suggest, and I think probably impossible. At least, not without synchronising on the OpOrdered, and doing everything that Barrier does, in the caller.

Note I have scrapped a lengthy message about how *expiring* atomically would also be ugly (and still would be necessary to some extent, making the code even uglier in the caller than it is in Barrier), as I hadn't yet realised that exposing atomically would be nearly impossible, which I hope underlines how difficult this is, and that encapsulating as much of it as possible in Barrier is a Good Thing. So that we only have to get it right the once.

Stylistically I also think it is *much* clearer to separate the two concepts.

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