This repository was archived by the owner on Oct 24, 2025. It is now read-only.
Merged
Conversation
Closed
This change allows a BTree user to quickly clone the tree, using copy-on-write logic to modify shared state. Both trees continue to reference the original tree's nodes for reading, thus the clone is O(1). Writes to either the original or new tree after the clone copy nodes instead of modifying them. These operations remain O(logn), but slow down slightly due to the additional mallocs/copies necessitated by the copy-on-write logic. Uses a copyOnWriteContext pointer at the tree and node level to determine which nodes are able to be modified and which are read-only and must be copied before modification. To simplify things, freelists have been made safe for concurrent access. With copy-on-write, keeping track of which freelists are being used by which btrees is very difficult. Consider the case: ```go t1 := New() t2 := t1.Clone() ``` What freelist should t1 and t2 have? Can you write to both t1 and t2 at once? With this, the answers are "they're sharing one", and "yes".
Contributor
|
@gconnell Just gotta say that this feature is an excellent addition! |
nvb
added a commit
to nvb/cockroach
that referenced
this pull request
Nov 6, 2018
google/btree#16 Release note: None
nvb
added a commit
to nvb/cockroach
that referenced
this pull request
Nov 13, 2018
google/btree#16 Release note: None
nvb
added a commit
to nvb/cockroach
that referenced
this pull request
Nov 13, 2018
google/btree#16 Release note: None
nvb
added a commit
to nvb/cockroach
that referenced
this pull request
Nov 15, 2018
google/btree#16 Release note: None
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change allows a BTree user to quickly clone the tree, using copy-on-write
logic to modify shared state. Both trees continue to reference the original
tree's nodes for reading, thus the clone is O(1).
Writes to either the original or new tree after the clone copy nodes instead
of modifying them. These operations remain O(logn), but slow down slightly due
to the additional mallocs/copies necessitated by the copy-on-write logic.
Uses a copyOnWriteContext pointer at the tree and node level to determine
which nodes are able to be modified and which are read-only and must be
copied before modification.
To simplify things, freelists have been made safe for concurrent access.
With copy-on-write, keeping track of which freelists are being used by
which btrees is very difficult. Consider the case:
What freelist should t1 and t2 have? Can you write to both t1 and t2 at
once? With this, the answers are "they're sharing one", and "yes".