> Data races are mostly prevented through Rust's ownership system: it's impossible to alias a mutable reference, so it's impossible to perform a data race.

https://doc.rust-lang.org/nomicon/races.html

Definition of data race on that page is very limited.

Also on the same page "Data races are mostly prevented through Rust's ownership system".

Rust does prevent data races (as in multiple threads writing to the same memory location is explicitly forbidden by the borrow checker), but it doesn’t prevent race conditions, which is a more general family of concurrency bugs.

In short, the borrow checker allows a single owner at all times, or it allows references to the object, abiding these rules: it may have any number of read-only references (they are safe to share), OR a single read-write reference.

A data race occurs when two or more parallel processes access the same data and at least one of them is mutating it.

Safe Rust forbids this through ownership and move semantics along with lifetime analysis. You may create any number of immutable aliases to data, or exactly one mutable alias. You cannot mix the two.

Unsafe allows you to (kind of) sidestep the automatic checking, but its your responsibility to uphold those conditions.

Sounds more or less (and pardon me if I'm oversimplifying) Java's "synchronized" keyword that most people stay away from just because it slows the code down so much you don't get the benefit of parallelization.

They couldn't be more different.

Java's synchronized keyword changes how code is interpreted to use expensive locking and data fences in order to prevent logical race conditions.

Rust's semantics do not alter the compiled code or insert any locking behavior. They prevent you from writing incorrect code to begin with.

In other words, Rust doesn't do anything magical to deal with data races at run time. It prevents you from expressing programs that have data races in the first place. It's a compile time analysis, not a run time behavior.

Interesting, thanks for clarifying.

Rust type system has primitive traits Send and Sync that formalize behavior expected for safe multithreaded concurrency. This way compiler can statically analyze the program and determine if it's safe.