Resource Management

Layer 1: Language Mechanics

Core Question

What ownership pattern does this resource need?

Before choosing a smart pointer, understand:

• Is ownership single or shared?

• Is access single-threaded or multi-threaded?

• Are there potential cycles?

Error → Design Question

Error

Don't Just Say

Ask Instead

"Need heap allocation"

"Use Box"

Why can't this be on stack?

Rc memory leak

"Use Weak"

Is the cycle necessary in design?

RefCell panic

"Use try_borrow"

Is runtime check the right approach?

Arc overhead complaint

"Accept it"

Is multi-thread access actually needed?

Thinking Prompt

Before choosing a smart pointer:

-

What's the ownership model?

• Single owner → Box or owned value

• Shared ownership → Rc/Arc

• Weak reference → Weak

-

What's the thread context?

• Single-thread → Rc, Cell, RefCell

• Multi-thread → Arc, Mutex, RwLock

-

Are there cycles?

• Yes → One direction must be Weak

• No → Regular Rc/Arc is fine

Trace Up ↑

When pointer choice is unclear, trace to design:

"Should I use Arc or Rc?"

    ↑ Ask: Is this data shared across threads?

    ↑ Check: m07-concurrency (thread model)

    ↑ Check: domain-* (performance constraints)

Situation

Trace To

Question

Rc vs Arc confusion

m07-concurrency

What's the concurrency model?

RefCell panics

m03-mutability

Is interior mutability right here?

Memory leaks

m12-lifecycle

Where should cleanup happen?

Trace Down ↓

From design to implementation:

"Need single-owner heap data"

    ↓ Use: Box<T>

"Need shared immutable data (single-thread)"

    ↓ Use: Rc<T>

"Need shared immutable data (multi-thread)"

    ↓ Use: Arc<T>

"Need to break reference cycle"

    ↓ Use: Weak<T>

"Need shared mutable data"

    ↓ Single-thread: Rc<RefCell<T>>

    ↓ Multi-thread: Arc<Mutex<T>> or Arc<RwLock<T>>

Quick Reference

Type

Ownership

Thread-Safe

Use When

Box<T>

Single

Yes

Heap allocation, recursive types

Rc<T>

Shared

No

Single-thread shared ownership

Arc<T>

Shared

Yes

Multi-thread shared ownership

Weak<T>

Weak ref

Same as Rc/Arc

Break reference cycles

Cell<T>

Single

No

Interior mutability (Copy types)

RefCell<T>

Single

No

Interior mutability (runtime check)

Decision Flowchart

Need heap allocation?

├─ Yes → Single owner?

│        ├─ Yes → Box<T>

│        └─ No → Multi-thread?

│                ├─ Yes → Arc<T>

│                └─ No → Rc<T>

└─ No → Stack allocation (default)

Have reference cycles?

├─ Yes → Use Weak for one direction

└─ No → Regular Rc/Arc

Need interior mutability?

├─ Yes → Thread-safe needed?

│        ├─ Yes → Mutex<T> or RwLock<T>

│        └─ No → T: Copy? → Cell<T> : RefCell<T>

└─ No → Use &#x26;mut T

Common Errors

Problem

Cause

Fix

Rc cycle leak

Mutual strong refs

Use Weak for one direction

RefCell panic

Borrow conflict at runtime

Use try_borrow or restructure

Arc overhead

Atomic ops in hot path

Consider Rc if single-threaded

Box unnecessary

Data fits on stack

Remove Box

Anti-Patterns

Anti-Pattern

Why Bad

Better

Arc everywhere

Unnecessary atomic overhead

Use Rc for single-thread

RefCell everywhere

Runtime panics

Design clear ownership

Box for small types

Unnecessary allocation

Stack allocation

Ignore Weak for cycles

Memory leaks

Design parent-child with Weak

Related Skills

When

See

Ownership errors

m01-ownership

Interior mutability details

m03-mutability

Multi-thread context

m07-concurrency

Resource lifecycle

m12-lifecycle