You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
The cloned tree from T1 may contain
1000
but not0
, 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.
The text was updated successfully, but these errors were encountered: