Rc, RefCell and Weak

When one owner is not enough

Ownership says each value has one owner. Sometimes data really has several owners: in a social app, a post may appear in many users' feeds; in a graph, several nodes point to the same node. Which owner should free it? The answer: whoever is last. Rc<T>, short for reference counted, does exactly this.

use std::rc::Rc;

fn main() {
    let post = Rc::new(String::from("Diwali sale starts today!"));
    let feed_a = Rc::clone(&post);     // count = 2
    let feed_b = Rc::clone(&post);     // count = 3
    println!("{}", Rc::strong_count(&post));   // 3
    drop(feed_a);
    println!("{}", Rc::strong_count(&post));   // 2
    println!("{feed_b}");
}   // the last owners are dropped: count reaches 0, the String is freed

post   --+
feed_a --+--> [ count: 3 | "Diwali sale starts today!" ]   (heap)
feed_b --+

Rc only gives shared (read-only) access: you cannot get a &mut through it, because other owners might be reading. Rc is for one thread only; its counter is not safe to update from several threads (Arc, in module 9, is the thread-safe version).

RefCell: borrowing rules at run time

Sometimes you know a change is safe, but the compiler cannot prove it. RefCell<T> moves the borrow check from compile time to run time. Through a shared reference to a RefCell, you call borrow() to get read access or borrow_mut() to get write access. RefCell counts the active borrows, and if you break the rules (for example two borrow_mut at once), it panics. This pattern is called interior mutability: changing the inside of something that looks immutable from outside.

use std::cell::RefCell;

let cart = RefCell::new(vec![120, 450]);
cart.borrow_mut().push(99);              // change through a shared binding
println!("{:?}", cart.borrow());          // [120, 450, 99]

let r1 = cart.borrow_mut();
// let r2 = cart.borrow_mut();            // PANIC at run time: already mutably borrowed
drop(r1);

Rc<RefCell<T>>: shared and changeable

use std::cell::RefCell;
use std::rc::Rc;

fn main() {
    let wallet = Rc::new(RefCell::new(1000));
    let parent = Rc::clone(&wallet);
    let child = Rc::clone(&wallet);

    *child.borrow_mut() -= 250;        // child spends
    *parent.borrow_mut() += 500;       // parent tops up
    println!("{}", wallet.borrow());    // 1250
}

Reference cycles and Weak

If A holds an Rc to B and B holds an Rc to A, neither count can reach zero, so neither is ever freed: a memory leak. Safe Rust prevents use-after-free, but it does not prevent leaks. The fix is Weak<T>: a non-owning pointer that does not keep the value alive. You make one with Rc::downgrade(&rc). To use it, call upgrade(), which returns Some(Rc) if the value still exists and None if it was freed.

parent --Rc--> child          (parent owns child: strong)
child  --Weak-> parent         (child only refers back: weak)

Which pointer when?

Common mistakes

• Writing post.clone() on an Rc and thinking it copies the data. It does not, but Rc::clone(&post) makes this clearer to readers.
• Holding a borrow_mut() and calling a function that calls borrow() on the same RefCell: a run-time panic "already mutably borrowed". Keep RefCell borrows short.
• Using Rc<RefCell<T>> everywhere to escape the borrow checker. It works but moves errors to run time; restructure first.
• Sending an Rc to another thread: the compiler refuses because Rc is not Send. Use Arc.