Learn how to code with the rust book

Reference Counting and Interior Mutability

Learning Rust with Bitcoin

Reference Counting and Interior Mutability

Reference Counting with RC
Interior Mutability with RefCell
Combining RC and RefCell for Shared Mutable State
Thread Safety and Concurrency Fundamentals
Shared State Concurrency with Mutex and Arc

Reference Counting with RC

Reference counting represents another fundamental type of smart pointer in Rust, designed specifically to enable multiple ownership scenarios. Unlike Box, which follows traditional single ownership rules where one entity owns the data, RC (Reference Counter) allows multiple parts of your code to share ownership of the same data simultaneously. This shared ownership model works through a counting mechanism that tracks how many references exist to a particular piece of data.

The reference counting system operates by maintaining an internal counter that increments each time you clone an RC and decrements when an RC is dropped. Memory is only freed when this counter reaches zero, ensuring that data remains valid as long as any reference exists. This approach prevents premature deallocation while enabling flexible data sharing patterns that would be impossible with simple Box ownership.

A practical example where RC is useful involves creating shared data structures like linked lists where multiple lists might reference the same tail portion. Consider attempting to create two separate lists that both reference a common subsequence. With Box ownership, this becomes impossible because moving the shared portion into the first list transfers ownership, preventing its use in the second list. RC solves this by allowing you to clone the reference rather than the underlying data, making the shared structure possible while maintaining memory safety.

When you clone an RC, you're not duplicating the internal data regardless of its size or complexity. Instead, you're creating another reference to the same memory location and incrementing the reference counter. This makes cloning RC instances efficient even for large data structures, as only the reference itself is copied while the underlying data remains in place.

Interior Mutability with RefCell

RefCell introduces interior mutability, which allows you to mutate data even when you only have an immutable reference to it. This capability fundamentally changes how Rust's borrowing rules are enforced by moving the checks from compile time to runtime. While normal references rely on the compiler to verify borrowing safety, RefCell performs these checks during program execution, providing greater flexibility at the cost of potential runtime panics.

The core principle behind RefCell involves maintaining the same borrowing rules that Rust normally enforces at compile time, but checking them dynamically. At any given moment, you can have either one mutable reference or any number of immutable references to the data inside a RefCell. If your code attempts to violate these rules by creating conflicting borrows simultaneously, the program will panic rather than produce undefined behavior.

This runtime checking enables certain programming patterns that the compiler might reject even when they're actually safe. The compiler's static analysis cannot always prove that complex borrowing patterns are correct, leading it to err on the side of caution. RefCell allows you to override these conservative restrictions when you're confident in your code's correctness, but this confidence comes with the responsibility of ensuring proper usage to avoid runtime crashes.

A common use case for RefCell involves mock objects in testing scenarios. When implementing a trait that only provides immutable access to self, but your mock implementation needs to track state changes internally, RefCell enables this pattern. You can wrap the internal state in a RefCell, allowing the mock to mutate its tracking data even through an immutable interface.

Combining RC and RefCell for Shared Mutable State

The combination of RC and RefCell creates a pattern for shared mutable state, where multiple owners can all potentially modify the same data. RC provides the shared ownership capability, while RefCell enables mutation through immutable references. This combination is useful in scenarios like graph structures, caches, or any situation where multiple parts of your program need both read and write access to shared data.

When you wrap a RefCell inside an RC, you create a structure that can be cloned and distributed throughout your program, with each clone providing access to the same underlying mutable data. All owners can potentially modify the data using RefCell's borrow_mut method, but they must still respect the borrowing rules at runtime. This pattern enables complex data sharing scenarios while maintaining Rust's safety guarantees through runtime checks.

However, this flexibility comes with important caveats regarding memory leaks and reference cycles. When using RC with RefCell, it becomes possible to accidentally create circular references where data structures reference themselves, either directly or through a chain of references. These cycles prevent the reference count from ever reaching zero, causing memory leaks because the data appears to always have active references even when it's no longer accessible from the rest of the program.

The solution to reference cycles involves using weak references, which don't contribute to the reference count used for memory management decisions. Weak references allow you to maintain connections between data structures without keeping them alive, breaking potential cycles while preserving the ability to access related data when it still exists.

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

// Simulating a channel state that multiple components need to access and modify
#[derive(Debug)]
struct ChannelState {
    channel_id: String,
    local_balance_msat: u64,
    remote_balance_msat: u64,
    is_active: bool,
}

fn main() {
    // Rc<RefCell<T>> allows multiple owners with interior mutability
    let channel = Rc::new(RefCell::new(ChannelState {
        channel_id: "abc123".to_string(),
        local_balance_msat: 1_000_000_000,  // 1M sats in msats
        remote_balance_msat: 500_000_000,
        is_active: true,
    }));

    // Clone Rc to share ownership (cheap - only increments counter)
    let channel_for_ui = Rc::clone(&channel);
    let channel_for_router = Rc::clone(&channel);

    // Reference count is now 3
    println!("Reference count: {}", Rc::strong_count(&channel));

    // UI component reads the state (immutable borrow)
    {
        let state = channel_for_ui.borrow();
        println!("UI shows balance: {} msats", state.local_balance_msat);
    } // borrow ends here

    // Router updates the state after a payment (mutable borrow)
    {
        let mut state = channel_for_router.borrow_mut();
        state.local_balance_msat -= 100_000_000; // Sent 100k sats
        state.remote_balance_msat += 100_000_000;
        println!("Router updated balances");
    } // mutable borrow ends here

    // Original reference can still read the updated state
    let state = channel.borrow();
    println!("New local balance: {} msats", state.local_balance_msat);

    // WARNING: This would panic at runtime!
    // let borrow1 = channel.borrow();
    // let borrow2 = channel.borrow_mut(); // PANIC: already borrowed
}

Thread Safety and Concurrency Fundamentals

Rust's approach to concurrency centers on preventing data races and memory safety issues at compile time. The type system enforces thread safety through traits like Send and Sync, which mark types as safe for transfer between threads or safe for concurrent access respectively. This compile-time verification catches many concurrency bugs that would only appear at runtime in other systems programming languages.

Creating threads in Rust follows a straightforward pattern using thread::spawn, which takes a closure to execute in the new thread and returns a handle for managing the thread's lifecycle. The spawned thread runs concurrently with the main thread, and you can use the join method on the handle to wait for completion. Without explicit joining, spawned threads may be terminated when the main thread exits, potentially cutting off incomplete work.

The move keyword becomes crucial when working with threads because closures passed to spawned threads often need to own their data rather than borrow it. Since spawned threads can outlive the scope that created them, borrowing from the parent scope creates potential lifetime violations. Moving data into the thread closure transfers ownership, ensuring the data remains valid for the thread's entire lifetime while preventing access from the original scope.

Message passing provides an alternative to shared state concurrency through channels that allow threads to communicate by sending data rather than sharing memory. Rust's standard library provides Multiple Producer Single Consumer (MPSC) channels, where multiple threads can send messages to a single receiving thread. This pattern eliminates many synchronization issues by avoiding shared mutable state entirely, instead relying on message exchange for coordination.

Shared State Concurrency with Mutex and Arc

When message passing isn't suitable, Rust provides traditional shared state concurrency through Mutex (mutual exclusion) combined with Arc (Atomic Reference Counter). Mutex ensures that only one thread can access protected data at a time by requiring threads to acquire a lock before accessing the data. The lock is automatically released when the guard object returned by the lock operation goes out of scope, preventing common deadlock scenarios caused by forgotten unlocks.

Arc serves as the thread-safe equivalent of RC, using atomic operations to manage the reference count safely across multiple threads. While RC works perfectly for single-threaded scenarios, its non-atomic reference counting creates race conditions when accessed from multiple threads. Arc's atomic counters ensure that reference count modifications happen safely even under concurrent access, making it suitable for sharing data across thread boundaries.

The combination of Arc and Mutex creates a pattern for shared mutable state in concurrent programs. By wrapping a Mutex in an Arc, you can clone the Arc to distribute access to the same mutex across multiple threads, with each thread able to acquire the lock and modify the protected data safely. This pattern provides the flexibility of shared state while maintaining Rust's safety guarantees through compile-time verification and runtime locking.

The Send and Sync traits work behind the scenes to ensure thread safety at compile time. Send indicates that a type can be safely transferred to another thread, while Sync indicates that references to a type can be safely shared between threads. Most types automatically implement these traits when their components are thread-safe, but some types like RC and RefCell explicitly don't implement them because they're not designed for concurrent access. This automatic trait implementation prevents accidental introduction of thread safety violations while allowing safe types to work seamlessly in concurrent contexts.

Quiz

dev3032.6

1/5

What is the key difference between how borrowing violations are handled with regular Rust references versus RefCell?