-
Notifications
You must be signed in to change notification settings - Fork 2
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
Stacked borrows Initiative #1
Comments
At the moment our tree implementations do not support thread safety. Can you make a benchmark of this proposal? Does it give any improvement in speed by itself? |
Any code in Rust is always thread-safe, otherwise it's UB. This code is works, but actually it's UB (later) let mut data = 10;
let ref1 = &mut data;
let ref2 = ref1 as *mut _;
unsafe {
*ref1 += 1;
*ref2 += 2;
}
Since the compiler uses two rules for optimization:
|
I can only promise compiler optimizations and no UB |
If Rust forces us to be not UB here, we should try to make code better. |
It is my initiative, but it will help us to make the code better and without possible UB |
Why is bad? let mut data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
let monitor = &data[..5];
data[..5].copy_from_slice(&[10, 9, 8, 7, 6]);
println!("hey, i immutable: {monitor:?}");
println!("{data:?}");
Ok, unsafe time: let mut data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
let monitor = unsafe { from_raw_parts(data.as_ptr(), data.len()).get_unchecked(..5) };
data[..5].copy_from_slice(&[10, 9, 8, 7, 6]);
println!("hey, i immutable: {monitor:?}");
println!("{data:?}"); It works:
But miri...
Hm. let mut data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
let monitor = unsafe { from_raw_parts(data.as_ptr(), data.len()).get_unchecked(..5) };
data[..5].copy_from_slice(&[10, 9, 8, 7, 6]);
let _ = monitor;
Why are you doing that? let mut data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
let monitor = unsafe { from_raw_parts(data.as_ptr().add(5), data.len() - 5) };
data[..5].copy_from_slice(&[10, 9, 8, 7, 6]); Nice. Miri silent. let mut data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
let (monitor, hot) = data.split_at_mut(5);
hot.copy_from_slice(&[10, 9, 8, 7, 6]); |
It's not exactly dangerous, but possible has potential bugs |
Develompent in stacked-borrows-initiative branch |
Now the experimental miri stacked borrows consider this as Undefined Behavior
I find it very difficult to thread safety when multiple mutable pointers are stored in different places.
I recommend using Yoda notation in regard to pointer storing.
This works well with stacked borrows:
The text was updated successfully, but these errors were encountered: