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