cassandra-commits mailing list archives

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


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

# 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
# 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.


\*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:
>             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

View raw message