Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementing clone #11

Open
XiangpengHao opened this issue Jan 22, 2023 · 0 comments
Open

Implementing clone #11

XiangpengHao opened this issue Jan 22, 2023 · 0 comments

Comments

@XiangpengHao
Copy link
Owner

XiangpengHao commented Jan 22, 2023

Congee can't be cloned (at least not with https://doc.rust-lang.org/std/clone/trait.Clone.html) due to the linearizability requirement (#8 (comment)).

Consider two threads:

T1:  ------|<----------- clone ---- ------>|-----
T2: ----------|insert(0)|---|insert(1000)|------

The cloned tree from T1 may contain 1000 but not 0, violating linearizability.

Two ways to mitigate this:
(1) Provide a fn clone(&mut self), and ask the caller to ensure no concurrent access. Since we don't provide a safe way to get mutable reference, users must go into unsafe (even UB) to get the mutable reference.
(2) Users can do a range scan over the tree and reconstruct the tree using the records scanned. Each range scan will read several records in a linearizable manner; to scan the entire tree, users must call range scan multiple times. There's no guarantee on multiple scans to be linearizable, but this is a performance-correctness tradeoff.

(I personally don't believe anybody needs linearizability over the entire tree clone; if such thing happens, I don't believe there's any better method than locking the entire tree)
So cloning over congee is a bad idea and if you frequently uses clone, congee might not be best data structure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant