cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5549) Remove Table.switchLock
Date Wed, 15 Jan 2014 04:44:29 GMT

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

Jonathan Ellis commented on CASSANDRA-5549:
-------------------------------------------

Pushed more refactorage to my branch.

I have a nagging feeling that OpOrdering could be done with two classes instead of three,
merging Barrier and Ordered:

{code}
        public void consume()
        {
            SharedState state = this.state;
            state.setReplacement(new State())
            state.doSomethingToPrepareForBarrier();

            state.opGroup = ordering.currentActiveGroup();
            state.opGroup.expire()
            state.opGroup.await();

            this.state = state.getReplacement();
            state.doSomethingWithExclusiveAccess();
        }

        public void produce()
        {
            Group opGroup = ordering.start();
            try
            {
                state.doProduceWork();
            }
            finally
            {
                opGroup.finishOne();
            }
        }
{code}

(We could still provide an accepts() method for the benefit of getMemtableFor, but I don't
see that requiring a 3rd class either.)

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

Mime
View raw message