Rc for Shared Ownership

A settings value is needed by a parser, a renderer, and a retry loop. With plain ownership you must pick one winner and hand out &Config references everywhere — workable until someone needs an owner that outlives the function that borrowed it. Rc<T> answers a different question: what if several variables owned the same value, and the value died only when the last owner did?

use std::rc::Rc;

struct Config { endpoint: String, retries: u32 }

let parser = Rc::new(Config { endpoint: String::from("https://api"), retries: 3 });
let renderer = Rc::clone(&parser);      // count 1 -> 2; NO deep copy of Config
let retry    = Rc::clone(&parser);      // count 2 -> 3

assert_eq!(Rc::strong_count(&parser), 3);
assert!(Rc::ptr_eq(&parser, &renderer));   // same allocation, three handles
drop(renderer);                        // 3 -> 2: nothing is freed, no destructor
drop(retry);                           // 2 -> 1
drop(parser);                          // 1 -> 0: NOW Config::drop runs, then dealloc

Rc::clone is a counter increment, not a data copy — that is the entire point, and the reason the API pushes you toward spelling it Rc::clone(&x) instead of x.clone() (clippy's clone_on_ref_ptr lint enforces the distinction, because x.clone() on an Rc<T> is ambiguous to readers: deep or shallow?). Under the hood the allocation carries two counts: the strong count for owners and a weak count for observers. The value's destructor runs when strong hits zero; the allocation itself is reclaimed only when strong and weak are both zero — remember that when we meet Weak.

The count is also a door back to unique access. When you hold the only handle, Rc lets you recover what shared ownership gave up:

let mut cache = Rc::new(vec![1, 2]);
*Rc::get_mut(&mut cache).unwrap() = vec![9];  // Some only while strong == 1 (and weak == 0)
let n = Rc::try_unwrap(cache).unwrap();       // Ok(inner) only while strong == 1

There is also Rc::make_mut, which clones the inner value on write when other handles exist — clone-on-write semantics, the same trick Cow pulls, now driven by the reference count. Everything here costs non-atomic increments and decrements: a plain read-modify-write on a usize in the allocation, which is fast because it happens on one thread.

Where Rc earns its keep is sharing that Box cannot express. Box<dyn EventLoop> has one owner, so it cannot live in two subsystems at once; Box<Config> cloned gives two configs that silently drift apart; but Rc<dyn EventLoop> held by every subsystem is one object with many owners. Typical homes: a parsed AST shared by a debugger and a compiler pass, a Rc<Cache> reachable from every handler of a single-threaded server, a callback list where each subscriber holds the shared service. The cost model is precise: Rc::new(v) makes one allocation containing strong, weak, and the T; size_of::<Rc<T>>() is one pointer, so the counts live with the data and handles stay cheap to pass.

One access rule trips everyone once. Reading through an Rc is free — it derefs to T — but writing is blocked: Rc implements Deref without DerefMut, so *rc = new_value will not compile while shared. Mutation must either happen while you hold the only handle (get_mut, above) or go through types built for it — the subject of Cell, RefCell, and Interior Mutability.

Interview framing: the questions that show up are "what does Rc::clone actually do?", "when does the value get dropped?", and "how do I get a &mut out of an Rc?" — all three are answered by the strong count. The chain of pointers here came from Deref Coercion; Rc derefs to its target exactly as Box does.

Try to send one to a worker thread and the compiler stops you:

use std::rc::Rc;
use std::thread;

fn main() {
    let data = Rc::new(vec![1, 2, 3]);
    thread::spawn(move || println!("{:?}", data));
}

error[E0277]: `Rc<Vec<{integer}>>` cannot be sent between threads safely
 --> src/main.rs:5:18
  |
5 |     thread::spawn(move || println!("{:?}", data));
  |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `Rc<Vec<{integer}>>` cannot be sent...
  |
note: required because it appears within the closure
note: required by a bound in `std::thread::spawn`

The bounds on thread::spawn are F: FnOnce() -> T + Send + 'static — the closure must be Send, and the closure is Send only if everything it captures is. Rc opts out of the auto traits with explicit negative impls (impl !Send for Rc<T>, impl !Sync for Rc<T>), and that refusal is not conservatism; it is arithmetic. Rc::clone does a non-atomic count += 1. Two threads cloning at once perform a read-modify-write race where one increment vanishes — the classic lost update:

thread A: reads 3          thread B: reads 3
thread A: writes 4         thread B: writes 4   <- one clone never counted
result: strong_count says 4, actual handles: 5  -> freed while in use -> use-after-free

A data race is undefined behavior in Rust's memory model, so the type system refuses to let the possibility exist: since Rc is neither Send nor Sync, any type that contains an Rc inherits the refusal (auto traits propagate through your structs), and the error surfaces at the first thread boundary — thread::spawn, a channel, a Mutex<T> holding it. The same E0277 appears when you push an Rc into an mpsc channel, because Sender::send demands T: Send for the same reason: the value would be produced on one thread and consumed on another.

The fix is Arc — atomic reference count, same API — and the trade is worth quantifying:

An uncontended atomic increment looks cheap, but N threads cloning one Arc in a hot loop turn the count into a shared cache line that every core must invalidate — clone storms can dominate a profile. That is why the design rule is not "Arc is the safe Rc" but "Rc unless ownership actually crosses a thread": single-threaded programs pay nothing for a guarantee they never use, by using Rc.

Interview framing: "Why is Rc not thread-safe?" is one of the most common Rust interview questions. Answer with the lost-update trace (two readers, two writers, one lost increment), then the consequence (free while in use, UB), then the mechanism (negative impls → E0277 at the boundary), and finish with Arc plus its cost. That fourth beat — naming the cost of atomics — is what distinguishes a prepared answer. The full shared-mutable pattern arrives in Arc and Mutex for Shared State; first, single-threaded sharing needs a mutation story of its own.

An observer wants to read a value, but it must not decide when that value dies. That is what Weak<T> is for: a pointer that can look but does not own.

use std::rc::{Rc, Weak};
use std::cell::RefCell;

struct Button { listeners: RefCell<Vec<Weak<Observer>>> }
struct Observer { id: u32 }

impl Observer {
    fn on_click(&self) { println!("observer {} woke", self.id); }
}

impl Button {
    fn subscribe(&self, o: &Rc<Observer>) {
        self.listeners.borrow_mut().push(Rc::downgrade(o));   // weak: count untouched
    }
    fn click(&self) {
        for weak in self.listeners.borrow().iter() {
            match weak.upgrade() {                            // strong handle, temporarily
                Some(obs) => obs.on_click(),                  // alive: upgrade succeeded
                None => println!("dead observer, dropping it"),// already freed
            }
        }
    }
}

let bob = Rc::new(Observer { id: 1 });
let button = Button { listeners: RefCell::new(Vec::new()) };
button.subscribe(&bob);
button.click();        // "observer 1 woke"
drop(bob);             // strong count hits 0 -> Observer dropped NOW
button.click();        // "dead observer, dropping it" — upgrade() returned None

Three properties make this work. Rc::downgrade(&x) returns a Weak without incrementing the strong count, so the observed value's lifetime is unchanged by who watches it. weak.upgrade() returns Option<Rc<T>> — Some with a fresh strong handle while the value lives, None after strong hit zero — so a watcher can never dereference freed data; it must handle the None. And the allocation survives for the weak handles even after the value is destroyed (the value drops at strong == 0; the block goes when weak also reaches 0), which is why upgrade can answer None at all instead of chasing a dangling pointer.

Why not just use Rc for the listeners? Because ownership in both directions is a leak: the button's Rc<Observer> keeps every observer alive forever, and if the observer held Rc<Button> back, neither would ever be freed — reference cycles are the one structural way safe Rust leaks memory, and the whole next topic is about breaking them. The pattern to remember: edges that express "contains / owns" are Rc; edges that express "knows about / points back" are Weak — a parent list owning children with Rc, children pointing at their parent with Weak, is the shape that stays collectable.

The Option return deserves its own note: a raw &T would need a separate liveness check that could dangle the instant after it ran, and a panicking upgrade().unwrap() would turn ordinary cleanup into crashes. Option<Rc<T>> bakes liveness into the value, so the compiler forces the match you saw — you cannot accidentally use a dead observer. Mechanics behind it, for completeness: downgrade bumps only the weak count; upgrade increments strong for the duration of the returned handle (rolling back if strong was already zero); Weak::strong_count reports 0 exactly when upgrade would fail; cloning or dropping a Weak touches nothing about lifetime.

Two practical details from the example. The RefCell around the listener Vec is what lets &self push a subscriber — a plain Vec would need &mut self, which a subscriber holding only &Button never gets; trading compile-time borrow checking for a runtime flag is the next topic's entire subject. And when a structure must begin self-referential — a node needing a Weak to itself before construction finishes — Rc::new_cyclic (stable since Rust 1.60) hands your constructor the Weak first, then completes the Rc.

Interview framing: "how do you avoid a memory leak with Rc?" starts here: Weak::upgrade returns an Option, observers never extend lifetime, and strong/weak counts explain both. Be ready to state the two-phase drop rule — value at strong == 0, allocation at weak == 0 — because it is the detail that separates a memorized answer from understanding.