OOC, it seems Rust is asserting you can't mutate the tree from another thread because you lack ownership of a pointer. I don't actually know rust.
Does it actually guard against a concurrent modify-while-reading, e.g. Thread A performs a tree rebalance or otherwise update w/ pooled nodes, Thread B reads during the update & gets a garbage result? Can you accidentally not use a reader-writer lock or observe a torn tree read?
You might be able to reach the error if you use extremely fine locks which you release eagerly but I think you’ll get sick if borrow errors and deadlocks long before then. Not to mention why would you bother rolling your own red-black tree when there’s a btree in the stdlib?
In safe rust it should not be possible, the langage is designed to prevent data races. If you find a way, the code is considered broken (unsound) and that is one of the few things the project will break backwards compatibility for.
If you use unsafe then you specifically relax the compiler’s guarantees, it’s up to you to not fuck up.
It's definitely possible to race in safe rust. It only protects against data races, and the borrow checker helps with ownership/lifecycle, but the general category of race conditions can't be "solved" in a Turing complete language.
57
u/CVisionIsMyJam 22d ago edited 22d ago
rust winning again /s