We’ve talked about why we chose to build Warp in Rust. Since making that decision, one thing that stands out is how productive we are as a team while still reaping the performance benefits of a systems-level language. in the past A big reason for that productivity is the borrow checker. By enforcing its rules at compile-time, Rust’s is able to make guarantees about the memory safety of our app, which lets us focus more of our energy on building the future of the terminal and less on chasing down use-after-free bugs. borrow checker At the same time, the borrow checker can be a source of frustration. Sometimes, you need to do something that breaks the rules but don’t want to throw safety out the window. Fortunately, the Rust standard library provides helpful types to let you do just that: break the rules! Shared Ownership Reference counting (Rc and Arc) Unique Borrows RefCell Locking Types (Mutex and RwLock) Atomics Shared Ownership The first borrow checker rule we’re going to break is single ownership: By default in Rust, every piece of data has a single owner, and when that owner goes out of scope, the data is cleaned up. This is great for ergonomics as you don’t have to worry about manually allocating and freeing memory! However, sometimes you don’t want data to have only a single owner. Maybe you want the data to pass through different parts of your program that will each run for different lengths and there’s no way to know how long in total the data needs to exist. Maybe you’re prototyping and don’t yet want to tackle ownership and lifetimes in a more concrete way. Whatever the reason, you really would like to have multiple owners for some data, so that it lasts as long as all of them combined. Reference Counting to the Rescue! Built into the Rust standard library are two types that provide shared ownership of the underlying data: and (short for ‘Reference counted’ and ‘Atomically reference counted’, respectively). Rc Arc Both of these types give shared ownership of the contained data by tracking the number of references and ensuring the data will last as long as there are any active references. They each implement and cloning increments the reference count while dropping one decrements it. The data is kept alive as long as there are references and only cleaned up once all of the clones have gone out of scope. For example, this snippet uses to share ownership of two pet objects between two owners: Clone Drop: Rc #[derive(Debug)]
struct Pet {
    name: String,
}

impl Pet {
    fn new(name: String) -> Self {
        Self { name }
    }
}

struct Person {
    pets: Vec<Rc<Pet>>,
}

fn main() {
    // Create two pets with shared ownership
    let cat = Rc::new(Pet::new("Tigger".into()));
    let dog = Rc::new(Pet::new("Chase".into()));

    // Create one person who owns both pets
    let brother = Person {
        pets: vec![cat.clone(), dog.clone()],
    };

    // Create another person who _also_ owns both pets
    let sister = Person {
        pets: vec![cat, dog],
    };

    // Even if one person gives up ownership, the other person still has shared ownership,
    // so the pets are kept around (yay!)
    drop(sister);
    println!("Pets: {:?}", brother.pets)
} Both types incur a small amount of runtime overhead to maintain the reference count. The key difference between them is that is thread safe, while isn’t. uses atomic operations to manage the reference count, which gives it a higher runtime cost but makes it safe to share between threads. If you’re only working in a single thread, then is the faster alternative. Arc Rc Arc Rc The last important fact about and is that they only allow you to get immutable references to the underlying data. Since they fundamentally represent shared data, allowing mutable references would violate Rust’s safety guarantees by allowing for data races and use-after-free errors. Rc Arc [2] Unique Borrows “But wait!,” you say, “What if I want to share mutable data between parts of my app?” Luckily, the next borrow checker rule we’re going to break is unique borrows: In order to mutate something, you need to have a unique (also called mutable) reference to the data. The borrow checker enforces that you can only have one mutable reference or any number of immutable references, but never a combination of the two, so you can’t ever mutate data that another part of the program is trying to read at the same time. This restriction works great most of the time, but we’re here to break the rules! Two cases where you might want to mutate data without having a mutable reference are: Caching an otherwise immutable calculation (i.e. memoization) The above shared ownership case with Rc or Arc For bending the compile-time borrowing rules, the compiler provides several helpful types, each with their own sets of drawbacks. All of them let you safely mutate data behind an immutable reference, using different approaches to make sure that your program is still safe. [3] RefCell First up is , which moves the enforcement of unique borrows from compile-time to runtime. Similar to , uses reference counting to track how many borrows are active while the program is running. If you ever try to take a mutable reference and another reference at the same time, will immediately panic! So when using , it’s up to you to make sure that your program doesn’t try to read and write the same data at the same time. RefCell Rc RefCell RefCell RefCell Here's an example of using to cache intermediate results for something that is otherwise immutable: RefCell struct FibonacciCalculator {
    cache: RefCell<HashMap<usize, usize>>,
}

impl FibonacciCalculator {
    /// Calculate the Nth fibonacci number, caching the result to prevent recalculation
    /// Note that this takes `&self`, not `&mut self`!
    fn calculate(&self, n: usize) -> usize {
        // Base case
        if n <= 2 {
            return 1;
        }

        // Check the cache
        if let Some(value) = self.cache.borrow().get(&n) {
            return *value;
        }

        // Calculate and cache the value
        let result = self.calculate(n - 1) + self.calculate(n - 2);

        self.cache.borrow_mut().insert(n, result);

        result
    }
} Also, the reference counting in is not thread safe, so it’s not possible to share data between threads. For mutating shared data between threads, we need to turn to our next tool. RefCell RefCell Locking Types The next two types are and , which both provide ways to access mutable references from an immutable reference in a thread-safe way. They do this by completely blocking the thread until it is safe to access the data. This provides a strong guarantee that the access is safe, but also has a major pitfall: Deadlocks. Deadlocks occur when two threads are blocked waiting for access to data that the other thread is holding. Similar to , it's up to you to make sure the logic of your program doesn't hold onto some data while waiting for access to other data leading to a deadlock. Mutex RwLock RefCell For example, the following snippet uses a Mutex to increment a counter in parallel in two new threads, then reads the final result from the original thread: // Create a shared, mutable counter
let counter = Arc::new(Mutex::new(0));

// Spawn one thread incrementing the counter
let counter1 = counter.clone();
let handle1 = thread::spawn(move || {
    for _ in 0..10 {
        *counter1.lock().unwrap() += 1;
    }
});

// Spawn another thread incrementing the counter
let counter2 = counter.clone();
let handle2 = thread::spawn(move || {
    for _ in 0..10 {
        *counter2.lock().unwrap() += 1;
    }
});

// Wait for the threads to complete
handle1.join().unwrap();
handle2.join().unwrap();

// Will write "Value: 20", since each thread incremented the counter 10 times.
println!("Value: {}", *counter.lock().unwrap()); The key difference between the two types is how they handle different kinds of access. A doesn’t care about whether you are trying to read or write the data, only a single thread can have access at a time. All other threads have to wait until the current consumer gives up their access. Mutex By contrast, follows Rust’s rules: Any number of threads can have read-only access to the underlying data or a single thread can have write access, but no combination. Attempting to obtain write access will block until there are no active readers and vice versa. RwLock The thread safe nature of these locking types makes them some of the most powerful ways to share mutable data, however it comes at a potentially significant performance cost: Locking the thread so that no other work can be done until the data is available. If our data is simple enough, the last type we’re going to look at can provide shared access across threads without needing to lock. Atomics are available for integer and boolean primitives. These types all provide methods to mutate or read the data as a single operation, so that nothing can happen in between and there is no possibility for data races. Atomic types For example, if you want to increment a counter, instead of reading the value, adding one, then writing the value, you would use the method that does all of that in a single block. fetch_add Atomics are often used as the building blocks for more complicated thread-safe sharing or one-off initialization. As mentioned above, Arc uses an atomic counter internally to manage the reference counting in a thread-safe way. The beauty of all of these types is that they provide a way to break the borrow checker rules while still maintaining Rust’s safety guarantees. Understanding which rules each type breaks is the key to knowing which tool you need. If you’re looking for shared ownership without copying, you want the reference counted types. If you’re looking for mutability without Rust’s strict mutable references, reach for interior mutability. And if you need shared mutable state, it’s not uncommon to use a combination of them: or are combinations for single- and multithreaded shared mutable ownership, respectively. Rc<RefCell<T>> Arc<Mutex<T>> If you’re interested in breaking more of Rust’s rules and pushing the terminal into the future, we’re hiring at Warp! Or if you’d just like to check out our Rust-based terminal, request early access below: Request early access to Warp First Published here

Different

The Problem With Promotion-Obsessed Cultures

Nominated for 2022 - HackerNoon Contributor of the Year - Management

Nominated for 2022 - HackerNoon Contributor of the Year - Engineering Management

Too Long; Didn't Read

Make resilience your competitive advantage

Make Your Rust Code More Rustic By Breaking Some Rules

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

The Problem With Promotion-Obsessed Cultures

102 Stories To Learn About Open Source Software

10 Top Open Source AI Technologies For Startups

10 Reasons You Should Quit Your HTTP Client

About Ten Open Source Technologies That Are Changing the World

The Problem With Promotion-Obsessed Cultures

102 Stories To Learn About Open Source Software

10 Top Open Source AI Technologies For Startups

10 Reasons You Should Quit Your HTTP Client

About Ten Open Source Technologies That Are Changing the World

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps