Data Races and Race Conditions

Safe Rust guarantees an absence of data races, which are defined as:

  • two or more threads concurrently accessing a location of memory
  • one of them is a write
  • one of them is unsynchronized

A data race has Undefined Behavior, and is therefore impossible to performin Safe Rust. Data races are mostly prevented through Rust’s ownership system:it’s impossible to alias a mutable reference, so it’s impossible to perform adata race. Interior mutability makes this more complicated, which is largely whywe have the Send and Sync traits (see below).

However Rust does not prevent general race conditions.

This is pretty fundamentally impossible, and probably honestly undesirable. Yourhardware is racy, your OS is racy, the other programs on your computer are racy,and the world this all runs in is racy. Any system that could genuinely claim toprevent all race conditions would be pretty awful to use, if not justincorrect.

So it’s perfectly “fine” for a Safe Rust program to get deadlocked or dosomething nonsensical with incorrect synchronization. Obviously such a programisn’t very good, but Rust can only hold your hand so far. Still, a racecondition can’t violate memory safety in a Rust program on its own. Only inconjunction with some other unsafe code can a race condition actually violatememory safety. For instance:

  1. use std::thread;
  2. use std::sync::atomic::{AtomicUsize, Ordering};
  3. use std::sync::Arc;
  5. let data = vec![1, 2, 3, 4];
  6. // Arc so that the memory the AtomicUsize is stored in still exists for
  7. // the other thread to increment, even if we completely finish executing
  8. // before it. Rust won't compile the program without it, because of the
  9. // lifetime requirements of thread::spawn!
  10. let idx = Arc::new(AtomicUsize::new(0));
  11. let other_idx = idx.clone();
  13. // `move` captures other_idx by-value, moving it into this thread
  14. thread::spawn(move || {
  15.     // It's ok to mutate idx because this value
  16.     // is an atomic, so it can't cause a Data Race.
  17.     other_idx.fetch_add(10, Ordering::SeqCst);
  18. });
  20. // Index with the value loaded from the atomic. This is safe because we
  21. // read the atomic memory only once, and then pass a copy of that value
  22. // to the Vec's indexing implementation. This indexing will be correctly
  23. // bounds checked, and there's no chance of the value getting changed
  24. // in the middle. However our program may panic if the thread we spawned
  25. // managed to increment before this ran. A race condition because correct
  26. // program execution (panicking is rarely correct) depends on order of
  27. // thread execution.
  28. println!("{}", data[idx.load(Ordering::SeqCst)]);
  1. use std::thread;
  2. use std::sync::atomic::{AtomicUsize, Ordering};
  3. use std::sync::Arc;
  5. let data = vec![1, 2, 3, 4];
  7. let idx = Arc::new(AtomicUsize::new(0));
  8. let other_idx = idx.clone();
  10. // `move` captures other_idx by-value, moving it into this thread
  11. thread::spawn(move || {
  12.     // It's ok to mutate idx because this value
  13.     // is an atomic, so it can't cause a Data Race.
  14.     other_idx.fetch_add(10, Ordering::SeqCst);
  15. });
  17. if idx.load(Ordering::SeqCst) < data.len() {
  18.     unsafe {
  19.         // Incorrectly loading the idx after we did the bounds check.
  20.         // It could have changed. This is a race condition, *and dangerous*
  21.         // because we decided to do `get_unchecked`, which is `unsafe`.
  22.         println!("{}", data.get_unchecked(idx.load(Ordering::SeqCst)));
  23.     }
  24. }