cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5549) Remove Table.switchLock
Date Fri, 29 Nov 2013 00:41:36 GMT

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

Benedict commented on CASSANDRA-5549:
-------------------------------------

I suggest the following (somewhat complex seeming approach), building on my patch for 3578:

We extract the CLS.Allocation object into a CommitState object that is allocated in CFS.apply()
prior to performing CL.add(). The CLS.AppendLock object is rewritten to be a more custom job
which we will for now call MutationBarrier, and extracted along with CommitState.

MutationBarrier will be a synchronisation primitive that permits issuing periodic barriers
that ensure operations started prior to the barrier have all completed, and also can be used
to create a token on an about-to-be-issued barrier that ensures operations started after the
barrier (when it *is* issued) know not to interfere with any state of an object that is using
the barrier. This was probably unclear, but the steps of CFS.apply() using it may clarify
it:

# Allocate CommitState, register operation with MutationBarrier
# CL.add() - on exit, has updated CommitState with position and segment of replay position.*
# Checks Memtable's BarrierToken to see if we are permitted to modify: 
#* if it's absent we simply make our modification and scoot;
#* if it's present and permits us to make our modification, we do so but ALSO update a ReplayPosition
property (with cas, ensuring it is >= the one we have in CommitState)
#* if it's present and does not permit us to modify, we look up its replacement Memtable and
repeat
# Release our hold on the MutationBarrier, signalling any waiters

When we flush a memtable, we:
# Set the ReplayPosition
# Create the replacement Memtable and chain it from ourselves
# Set the BarrierToken
# Wait on the Barrier
# Flush to disk, using the ReplayPosition we have maintained

Note that we will no longer perform any reference counting on the Memtables. I will ensure
that the mutation calls are all non-blocking, but may for correctness and simplicity make
those attempting to flush/issue a new barrier take out a (possibly spin-) lock on the MB in
order to issue a Token atomically.

Thoughts?

\*CL.sync() will use the MB to fulfil the AppendLock role also. CL.add() will release a hold
on the MB that is related to CL only, to permit CL to proceed immediately.

> Remove Table.switchLock
> -----------------------
>
>                 Key: CASSANDRA-5549
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5549
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>            Assignee: Vijay
>              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#6144)

Mime
View raw message