[ https://issues.apache.org/jira/browse/CASSANDRA-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13835923#comment-13835923 ]
Jonathan Ellis edited comment on CASSANDRA-3578 at 12/1/13 2:12 AM: -------------------------------------------------------------------- bq. We point next to next, which is absolutely correct I understand what sync is doing; my point is that xxxxSyncMarkerPosition always points to the *last* offset before which the contents are synced, which we'll revisit when we sync again / write the next marker (referred to appropriately as {{nextMarker}} in the code). Your own comments refer to "last" or "previous" in multiple places which speaks to how difficult it is to avoid thinking of it that way. :) (N.B. This is also clear in the usage of isFullySynced -- intuitively, we want to know if "the *last* place we synced was the end of the buffer" which is unclear if the variable is named *next*.) was (Author: jbellis): bq. We point next to next, which is absolutely correct I understand what sync is doing; my point is that xxxxSyncMarkerPosition always points to the *last* offset before which the contents are synced, which we'll revisit when we sync again / write the next marker (referred to appropriately as {{nextMarker}} in the code). Your own comments refer to "last" or "previous" in multiple places which speaks to how difficult it is to avoid thinking of it that way. :) (N.B. This is also clear in the usage of isFullySynced -- intuitively, we want to know if "the *last8 place we synced was the end of the buffer" which is unclear if the variable is named *next*.) > 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)