It is, in large part. The rules on ownership and borrowing mean that it is not supposed to be possible to change memory that something else can be concurrently reading from. That means you are forced to obtain references through protective mechanisms, which should protect from race conditions.
All of that can go out of the window if you use unsafe.
Rust doesn’t have a scheduler.
The issue is the false assumption, that the remove operation can safely be done without taking a lock. This can be done in some specific data structures using atomic operations, but here the solution was to just take the lock. The same thing could have happened in a C code base but without the unsafe block indicating where to look for the bug.
It is, in large part. The rules on ownership and borrowing mean that it is not supposed to be possible to change memory that something else can be concurrently reading from. That means you are forced to obtain references through protective mechanisms, which should protect from race conditions.
All of that can go out of the window if you use
unsafe.Note how the ticket cited is in an unsafe block, because it uses the OS scheduler, not its own. It is not Rust’s fault.
Rust doesn’t have a scheduler.
The issue is the false assumption, that the
removeoperation can safely be done without taking a lock. This can be done in some specific data structures using atomic operations, but here the solution was to just take the lock. The same thing could have happened in a C code base but without the unsafe block indicating where to look for the bug.Yeah, I’m not saying it’s rust’s fault. Restricting this to unsafe makes it a lot easier to reason about where such problems can occur.
I just don’t think anyone should give the impression that rust’s memory safety is not about race conditions.