[
https://issues.apache.org/jira/browse/CASSANDRA-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13835663#comment-13835663
]
Benedict edited comment on CASSANDRA-3578 at 11/30/13 12:03 PM:
----------------------------------------------------------------
Just realised there's a deadlock possibility when you move flushDataFrom() into
executing on the CLSManager thread: somebody owning the switchLock can be
performing a CL.add(), which is waiting on the CLSManager, which could itself
be waiting on the switch lock.
This same scenario can occur even when we move to the changes I propose in
CASSANDRA-5549.
was (Author: benedict):
Just realised there's a deadlock possibility when you move flushDataFrom() into
executing on the CLSManager thread: somebody with a readlock on switchLock can
be perform a CL.add() which is waiting on the CLSManager, which could be
waiting on the switch lock.
This same scenario can occur even when we move to the changes I propose in
CA5549.
> Multithreaded commitlog
> -----------------------
>
> Key: CASSANDRA-3578
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3578
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Benedict
> Priority: Minor
> Labels: performance
> Attachments: 0001-CASSANDRA-3578.patch, ComitlogStress.java,
> Current-CL.png, Multi-Threded-CL.png, TestEA.java, latency.svg, oprate.svg,
> parallel_commit_log_2.patch
>
>
> Brian Aker pointed out a while ago that allowing multiple threads to modify
> the commitlog simultaneously (reserving space for each with a CAS first, the
> way we do in the SlabAllocator.Region.allocate) can improve performance,
> since you're not bottlenecking on a single thread to do all the copying and
> CRC computation.
> Now that we use mmap'd CommitLog segments (CASSANDRA-3411) this becomes
> doable.
> (moved from CASSANDRA-622, which was getting a bit muddled.)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
