[
https://issues.apache.org/jira/browse/CASSANDRA-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874840#comment-13874840
]
Benedict commented on CASSANDRA-5549:
-------------------------------------
bq. The problem is that it's not "just" a memory fence, but is tied to the
Group behavior. (Once issued, the old group is sealed and a new Group started.)
True, but from the point of view of the Barrier API, that doesn't really seem
like important information to me, although it is a necessity of function that
it happens. I think it is important to convey, especially, that the Barrier
itself doesn't really exist until you call this method, it's just a place
holder, which seal() doesn't seem to. A few alternatives: fix(), impose(),
slice().
Coming up a bit empty on really good alternatives, though, and probably not
worth much more discussion. I am not completely against seal(), as the word
sounds good when said with Barrier. So whatever works for you.
> 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)
