Jack O'Connor provides a fast-paced introduction to Rust's borrow checker, lifetimes, move semantics, and concurrency model for developers with a C++ background.
Slides: jacko.io/firehose_of_rust
The slower version of this talk (2h32m): youtu.be/FSyfZVuD32Y
Contents:
introduction
references and mutable aliasing
reference lifetime examples
mutable aliasing examples
move semantics
Arc Mutex String
outro
Links from screenshots in slides:
godbolt.org/z/891s6z4Tbyoutu.be/xnqTKD8uD64?t=1380godbolt.org/z/fK1WchMYfyoutu.be/lkgszkPnV8g?t=1750
Errata:
- The example raw pointer code shown at is valid today according to Miri, but it's not the best approach, and it's possible that it will become invalid before the rules for unsafe Rust finally stabilize. The worry is that creating a temporary shared reference on line 3 implies that the mutable reference on line 2 is definitely dead, which could mean that the raw pointer on line 2 is also dead in some sense. A more conservative approach would be to use .as_mut_ptr() to get a pointer to the first element and then .add() to get a pointer to the second element, without creating any extra references to the array. (Update: The "Tree Borrows" model for Miri also allows the example as written. perso.crans.org/vanille/treebor/)
- At I described both C++ copy constructors and the Rust .clone() method as making a "deep copy". That's sometimes the right way to think about it, but not when pointers and references get involved. Indeed, the final section relies on shallow cloning to share a reference-counted object across threads. C++ and Rust behave very similarly here, and understanding that ".clone() works like a C++ copy constructor" tells you most of what you need to know about a wide variety of different types.
- At I said that Mutex in Rust needs a heap allocation on Linux because of how the underlying system calls work. That's mostly incorrect. It's true that a futex can't be moved while locked, and that does matter for std::mutex in C++. But it doesn't actually matter in Rust, because a Mutex is borrowed and immovable while it's locked. Instead, the issue in Rust is that POSIX doesn't guarantee that a pthread_mutex_t is movable (although many implementations are movable in practice). See twitter.com/m_ou_se/status/1403413967846977538. (Update: As of Rust 1.62, released in June 2022, Mutex on Linux creates a futex directly and no longer needs a heap allocation. Mutex still uses pthreads and heap allocation on some other Unix systems.)
- At I use Arc+Mutex to get the multithreaded Rust example working. That's a common idiom in Rust, and it's good to demo it, but as of Rust 1.63 (August 2022) you can also use "scoped" threads: doc.rust-lang.org/std/thread/fn.scope.html
Why it's here
1 person recommends this
What people say. Recommended as an excellent, high-density introduction to Rust's memory model and borrow checker specifically tailored for C++ programmers.
Moments people linked to
o
u/oconnor663in r/programming • Recommends
On “The Tor Project announces Arti, a Tor implementation written in Rust from scratch”
Totally! This is a big topic, but here are a few highlights:
- **The borrow checker.** This isn't specific to threading, but it's a fundamental part of how Rust works. Whenever you take a pointer/reference/borrow of some object, Rust tracks the lifetime of that borrow. If you try to keep using it after the original object has gone out of scope and been destroyed, Rust is always going to detect this issue at compile time and refuse to compile your program. This can happen within a single thread of course, but it's also a common issue across threads. An object might be bound to some stack frame in the thread that created it, but a pointer to that object might wind up getting used by another t…
